Журналы GC перезаписываются при сбое JVM - PullRequest
Новая
       26

Журналы GC перезаписываются при сбое JVM

0 голосов
/ 07 сентября 2018

Я настраиваю наш продукт для G1GC, и в ходе этого тестирования у меня регулярно возникают сбои в работе Spark Workers, что, конечно, приводит к сбою JVM. Когда это происходит, JVM Spark Worker / Executor автоматически перезапускает себя, который затем перезаписывает журналы GC, которые были записаны для предыдущей JVM Executor.

Если честно, я не совсем уверен в том, как механизм JVM Executor перезапускается, но я запускаю службу Spark Driver через init.d, которая, в свою очередь, вызывает скрипт bash. В этом сценарии я использую метку времени, которая добавляется к имени файла журнала GC: * ​​1004 * 

today=$(date +%Y%m%dT%H%M%S%3N)

SPARK_HEAP_DUMP="-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${SPARK_LOG_HOME}/heapdump_$$_${today}.hprof"
SPARK_GC_LOGS="-Xloggc:${SPARK_LOG_HOME}/gc_${today}.log -XX:LogFile=${SPARK_LOG_HOME}/safepoint_${today}.log"

GC_OPTS="-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:+PrintFlagsFinal -XX:+PrintJNIGCStalls -XX:+PrintTLAB -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=15 -XX:GCLogFileSize=48M -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintAdaptiveSizePolicy -XX:+PrintHeapAtGC -XX:+PrintGCCause -XX:+PrintReferenceGC -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1"

Я думаю, проблема в том, что этот скрипт отправляет эти параметры драйверу Spark, который затем передает их исполнителям Spark (через аргумент -Dspark.executor.extraJavaOptions), которые являются отдельными серверами, и когда происходит сбой JVM Executor, он просто использует команду, которая была первоначально отправлена ​​для запуска резервного копирования, что будет означать, что часть метки времени в имени файла журнала GC является статической: 

SPARK_STANDALONE_OPTS=`property ${SPARK_APP_CONFIG}/spark.properties "spark-standalone.extra.args"`
SPARK_STANDALONE_OPTS="$SPARK_STANDALONE_OPTS $GC_OPTS $SPARK_GC_LOGS $SPARK_HEAP_DUMP"

exec java ${SPARK_APP_HEAP_DUMP} ${GC_OPTS} ${SPARK_APP_GC_LOGS} \
    ${DRIVER_JAVA_OPTIONS} \
    -Dspark.executor.memory=${EXECUTOR_MEMORY} \
    -Dspark.executor.extraJavaOptions="${SPARK_STANDALONE_OPTS}" \
    -classpath ${CLASSPATH} \
    com.company.spark.Main >> ${SPARK_APP_LOGDIR}/${SPARK_APP_LOGFILE} 2>&1 &

Это затрудняет мне отладку причины ошибок, так как я теряю активность и состояние рабочих, которые привели к сбою JVM. Любые идеи о том, как я могу справиться с этой ситуацией и сохранить журналы GC на рабочих, даже после сбоя JVM / segfault?

1 Ответ

0 голосов
/ 13 сентября 2018

Если вы используете Java 8 и выше, вы можете покончить с этим, добавив% p к имени файла журнала, чтобы ввести PID, который будет своего рода уникальным для сбоя.

...