我正在运行一个spark应用程序,其中包含两个xms/xmx为32的执行器 gb和spark.JARN.excutor.memoryoverhead as 6 国标。
我看到应用程序的物理内存不断增加,最终被节点管理器杀死:
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 国标。
我查了所有的rss /proc/pid/smaps
,它的值与yarn报告的物理内存和top命令中显示的物理内存的值相同。
我检查了堆是否有问题,但是堆外/本机内存正在增加。我使用了像visualvm这样的工具,但是没有发现任何东西在增加。MaxDirectMMerory也没有超过600 mb。活动线程的峰值数为70-80,线程堆栈大小不超过100 mb。元空间大小约为60-70 mb。
仅供参考,我使用的是spark 1.2和hadoop 2.4.0,我的spark应用程序基于spark sql,它是一个hdfs读/写密集型应用程序,在spark sql的内存缓存中缓存数据。
我应该在哪里调试内存泄漏,或者已经有工具了吗?
1条答案
按热度按时间628mspwn1#
我终于摆脱了这个问题。问题是spark sql的Parquet写入路径中创建的压缩器没有得到回收,因此,我的执行者正在为每个Parquet写入文件创建一个全新的压缩器(从本机内存),从而耗尽物理内存限制。
我在parquet jira中打开了以下错误,并提高了相同的pr:-
https://issues.apache.org/jira/browse/parquet-353
这解决了我这边的记忆问题。
p、 只有在Parquet地板写密集型应用程序中才能看到这个问题。