背景
在生產環境中，為了提高任務提交的響應速度，我們研發了類似 Spark Jobserver 的服務，各種類型的 spark 任務復用已經啟動的 Spark Application，避免了 sparkContext 初始化冷啟動的過程。
可復用Spark服務的內存是固定的，因此又開放了用戶自定義 Executor 內存的權限，用戶為了避免自己的任務因內存不足而失敗，往往會把內存設置的很大，從而帶來了內存濫用的問題。
jvm-profiler
一般來說監控 spark 內存有2種方式
- 通過 Spark ListenerBus 獲取 Executor 內部的內存使用情況 ，現在能獲取的相關信息還比較少，在 https://github.com/apache/spark/pull/21221 合進來后就能采集到executor 內存各個邏輯分區的使用情況。
- 通過 Spark Metrics 將 JVM 信息發送到指定的 sink，用戶也可以自定義 Sink 比如發送到 kafka/Redis。
Uber 最近開源了 jvm-profiler，采集分布式JVM應用信息，可以用于 debug CPU/mem/io 或者方法調用的時間等。比如調整Spark JVM 內存大小，監控 HDFS Namenode RPC 延時，分析數據血緣關系。
應用于 Spark 比較簡單
每5S采集一次JVM信息，發送到 kafka profiler_CpuAndMemory topic
hdfs dfs -put jvm-profiler-0.0.9.jar hdfs://hdfs_url/lib/jvm-profiler-0.0.9.jar
--conf spark.jars=hdfs://hdfs_url/lib/jvm-profiler-0.0.9.jar
--conf spark.executor.extraJavaOptions=-javaagent:jvm-profiler-0.0.9.jar=reporter=com.uber.profiling.reporters.KafkaOutputReporter,metricInterval=5000,brokerList=brokerhost:9092,topicPrefix=profiler_
消費后存入HDFS用于分析。
分析
hive 表結構
| app_id | process_id | role | heap_mem_max | heap_mem_used | process_cpu_load | epoch_millis |
|---|
對用戶自定義內存的任務進行分析
用戶自定義內存調度任務，75%的任務內存使用率低于80%，可以進行優化。
用戶自定義內存調度任務
用戶自定義內存開發任務，45%的任務內存使用率低于20%，用戶存在不良使用習慣。
用戶自定義內存開發任務
總結
通過采集 jvm 的最大使用值和設定值，可以解決下述問題。
- 內存濫用
- 監控應用內存使用趨勢，防止數據增長導致內存不足
- Spark Executor 默認內存設置不合理
根據應用的使用預計內存減少情況
- executor 默認內存減少10%，平均每個任務能釋放 60G 內存
- 自定義內存調度任務利用率提高到 70%，平均每個任務能釋放 450G 內存
- 自定義內存開發任務利用率提高到 70%，平均每個任務能釋放 550G 內存
參考
JVM Profiler: An Open Source Tool for Tracing Distributed JVM Applications at Scale
