HeartSaVioR commented on a change in pull request #27398: [SPARK-30481][DOCS][FOLLOWUP] Document event log compaction into new section of monitoring.md URL: https://github.com/apache/spark/pull/27398#discussion_r373176937
########## File path: docs/monitoring.md ########## @@ -95,6 +95,44 @@ The history server can be configured as follows: </tr> </table> +### Applying compaction of old event log files + +A long-running streaming application can bring a huge single event log file which may cost a lot to maintain and +also requires bunch of resource to replay per each update in Spark History Server. + +Enabling <code>spark.eventLog.rolling.enabled</code> and <code>spark.eventLog.rolling.maxFileSize</code> would +let you have multiple event log files instead of single huge event log file which may help some scenarios on its own, +but it still doesn't help you reducing the overall size of logs. + +Spark History Server can apply 'compaction' on the rolling event log files to reduce the overall size of +logs, via setting the configuration <code>spark.history.fs.eventLog.rolling.maxFilesToRetain</code> on the +Spark History Server. + +When the compaction happens, History Server lists the all available event log files, and considers the event log files older than +retained log files as a target of compaction. For example, if the application A has 5 event log files and +<code>spark.history.fs.eventLog.rolling.maxFilesToRetain</code> is set to 2, first 3 log files will be selected to be compacted. Review comment: The intention was to fail the compaction task for the application log which is submitted to ExecutorService. But I seem to miss logging and swallowing the exception - currently it just leaves the exception be propagated, which may be swallowed, but may not be "logged". I'll create a new FOLLOW-UP PR to cover it. Thanks for reminding. We could be still wondering about blacklisting the application log when compaction task fails. We may be able to blacklist the application log if the task fails due to the lack of read permission, but we may not want to blacklist if it lacks write permission as SHS can still replay the log - only compact and cleanup would affect. Given that listing application log executes earlier than compacting, log should have been blacklisted when listing application log if the read permission lacks. There might be some edge-case where permission for each log file is different, but I would ignore the edge-case as they will be created when the application is live so it doesn't sound possible unless it's manually modified. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org
