不断增加 YARN 中 Spark 应用程序的物理内存答案

【问题标题】：Ever increasing physical memory for a Spark application in YARN不断增加 YARN 中 Spark 应用程序的物理内存
【发布时间】：2015-10-17 06:14:31
【问题描述】：

我在 YARN 中运行一个 Spark 应用程序，它有两个执行器，Xms/Xmx 为 32 GB，spark.yarn.excutor.memoryOverhead 为 6 GB。

我看到应用程序的物理内存不断增加，最终被节点管理器杀死：

2015-07-25 15:07:05,354 WARN org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Container [pid=10508,containerID=container_1437828324746_0002_01_000003] is running beyond physical memory limits. Current usage: 38.0 GB of 38 GB physical memory used; 39.5 GB of 152 GB virtual memory used. Killing container.
Dump of the process-tree for container_1437828324746_0002_01_000003 :
    |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE
    |- 10508 9563 10508 10508 (bash) 0 0 9433088 314 /bin/bash -c /usr/java/default/bin/java -server -XX:OnOutOfMemoryError='kill %p' -Xms32768m -Xmx32768m  -Dlog4j.configuration=log4j-executor.properties -XX:MetaspaceSize=512m -XX:+UseG1GC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:gc.log -XX:AdaptiveSizePolicyOutputInterval=1  -XX:+UseGCLogFileRotation -XX:GCLogFileSize=500M -XX:NumberOfGCLogFiles=1 -XX:MaxDirectMemorySize=3500M -XX:NewRatio=3 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=36082 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=100M -XX:MaxMetaspaceSize=512m -XX:CompressedClassSpaceSize=256m -Djava.io.tmpdir=/data/yarn/datanode/nm-local-dir/usercache/admin/appcache/application_1437828324746_0002/container_1437828324746_0002_01_000003/tmp '-Dspark.driver.port=43354' -Dspark.yarn.app.container.log.dir=/opt/hadoop/logs/userlogs/application_1437828324746_0002/container_1437828324746_0002_01_000003 org.apache.spark.executor.CoarseGrainedExecutorBackend akka.tcp://sparkDriver@nn1:43354/user/CoarseGrainedScheduler 1 dn3 6 application_1437828324746_0002 1> /opt/hadoop/logs/userlogs/application_1437828324746_0002/container_1437828324746_0002_01_000003/stdout 2> /opt/hadoop/logs/userlogs/application_1437828324746_0002/container_1437828324746_0002_01_000003/stderr

我禁用了 YARN 的参数“yarn.nodemanager.pmem-check-enabled”，发现物理内存使用量达到了 40 GB。

我检查了/proc/pid/smaps中的总RSS，它与Yarn报告的物理内存值相同，在top命令中看到。

我检查了堆没有问题，但是堆外/本机内存中的某些东西正在增加。我使用了 Visual VM 之类的工具，但没有发现任何增加的东西。 MaxDirectMmeory 也不超过 600 MB。活动线程的峰值数量为 70-80，线程堆栈大小未超过 100 MB。 MetaspaceSize 约为 60-70 MB。

仅供参考，我使用的是 Spark 1.2 和 Hadoop 2.4.0，我的 Spark 应用程序基于 Spark SQL，它是 HDFS 读/写密集型应用程序，并将数据缓存在 Spark SQL 的内存缓存中。

我应该去哪里调试内存泄漏或者是否已经有工具？

【问题讨论】：

标签： java hadoop memory apache-spark apache-spark-sql

【解决方案1】：

最后我能够摆脱这个问题。问题是在 Spark SQL 的 parquet 写入路径中创建的压缩器没有被回收，因此，我的执行程序正在为每个 parquet 写入文件创建一个全新的压缩器（从本机内存），从而耗尽了物理内存限制。

我在 Parquet Jira 中打开了以下错误并提出了相同的 PR：-

https://issues.apache.org/jira/browse/PARQUET-353

这解决了我的内存问题。

附： - 您只会在 Parquet 写入密集型应用程序中看到此问题。

【讨论】：

您是如何发现它是 Parquet 的？我们有类似的问题（但我们没有使用镶木地板），我们不确定如何找到罪魁祸首
我们有一个类似的（堆外）OOM 问题，很难追踪。原来它是用于 gzip 输出的 Hadoop 本机库（hadoop.native.lib）。我们现在在启动时执行此操作，虽然性能不太好，但泄漏消失了： JobConf jobConf = new JobConf(sc.hadoopConfiguration()); jobConf.setBoolean("hadoop.native.lib", false);