Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[SPARK-23429][CORE] Add executor memory metrics to heartbeat and expose in executors REST API #20940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
[SPARK-23429][CORE] Add executor memory metrics to heartbeat and expose in executors REST API #20940
Changes from 1 commit
48eab1db348901df05fb6b02e76c5b5a36ebc8d093ae9172015298b9529f8475e24fc644a9f8e6151f29fe2b7a4a7c19d928ea4e3a135182441d0d08020f667cf9fab66a3a5a1035aaa359375e5cfd5fa16ef6ba5197562a355236cccaaa1d8379e5d3bd043c5c8b541822ecdb2329fbd9ca1c94807d38f2ac087d65e531249007e6ade5cb9452401d766ea2c926acfd23a805b6935ffe9982506ab134c2c1fe646a73457710a68c8d40a7932471bad81f29e10f45bb7c1654e252468a61b7247f94f362649888495034af3323b15e179658adb222b4f1e8b97c7570dc7622be87611bbc604d65271c891653fe023cb820475a18309d960dee904dfa6a2289e0b191220f93b91682002b14291b0ab7b9611018be44b070360323e61a83ae0d4dfd74625892f3558f31bcbb41a073f2853c0964936931022083cf2250037360461482fd990a914844a61cc66a005ae74730ffb530a9172aed4101d3990daaf39e82c1ca3c505fccdae1e3b876310a8cdcce4694f81fa47f09a9e9a9066470c94e488bb0df2d5bec4846bb2b51b08c43e1341659e10f69d96c3e30deaa526e19f76a4718809ea8d3de55953bb3fde5ae6b4660074a7f90dd97f61d758dc32b4bcd7bc853dae8a388c48085ac3a86faf70f46dd87d30eafbdf42293a0f2448d248770add8e82cb68c8f3ac6efcfc64b24f0419d9c248bbe1a828ae0126File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
This change introduces two optimizations to help speed up generation of listing data when parsing events logs. The first one allows the parser to be stopped when enough data to create the listing entry has been read. This is currently the start event plus environment info, to capture UI ACLs. If the end event is needed, the code will skip to the end of the log to try to find that information, instead of parsing the whole log file. Unfortunately this works better with uncompressed logs. Skipping bytes on compressed logs only saves the work of parsing lines and some events, so not a lot of gains are observed. The second optimization deals with in-progress logs. It works in two ways: first, it completely avoids parsing the rest of the log for these apps when enough listing data is read. This, unlike the above, also speeds things up for compressed logs, since only the very beginning of the log has to be read. On top of that, the code that decides whether to re-parse logs to get updated listing data will ignore in-progress applications until they've completed. Both optimizations can be disabled but are enabled by default. I tested this on some fake event logs to see the effect. I created 500 logs of about 60M each (so ~30G uncompressed; each log was 1.7M when compressed with zstd). Below, C = completed, IP = in-progress, the size means the amount of data re-parsed at the end of logs when necessary. ``` none/C none/IP zstd/C zstd/IP On / 16k 2s 2s 22s 2s On / 1m 3s 2s 24s 2s Off 1.1m 1.1m 26s 24s ``` This was with 4 threads on a single local SSD. As expected from the previous explanations, there are considerable gains for in-progress logs, and for uncompressed logs, but not so much when looking at the full compressed log. As a side note, I removed the custom code to get the scan time by creating a file on HDFS; since file mod times are not used to detect changed logs anymore, local time is enough for the current use of the SHS. Author: Marcelo Vanzin <[email protected]> Closes #20952 from vanzin/SPARK-6951.Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.