Question

我正在为G1GC调整产品，作为该测试的一部分，我的Spark Workers遇到了定期的段错误，这当然会导致JVM崩溃。发生这种情况时，Spark Worker / Executor JVM将自动重启，然后覆盖为先前的Executor JVM编写的GC日志。

说实话，我不太确定Executor JVM如何自行重启的机制，但是我通过init.d启动了Spark Driver服务，该服务反过来又调用了bash脚本。我确实在该脚本中使用了时间戳记，该时间戳记附加在GC日志文件名之后：

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参数），它们都是单独的服务器，并且当Executor JVM崩溃时，它仅使用最初发送的命令来启动备份，这意味着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 &

这使我很难调试segfaults的原因，因为我丢失了导致JVM崩溃的Workers的活动和状态。关于如何处理这种情况并将GC日志保留在Workers上的任何想法，即使在JVM崩溃/段错误之后也是如此？

Answer 1

如果您使用的是Java 8及更高版本，则可以考虑通过在日志文件名中添加％p来引入它来引入PID，PID在每次崩溃时都是唯一的。

JVM崩溃时GC日志被覆盖

1 个答案: