[HADOOP] YARN의 Spark 응용 프로그램을위한 실제 메모리 증가

YARN의 Spark 응용 프로그램을위한 실제 메모리 증가

나는 Xarnes / Xmx가 32GB이고 spark.yarn.excutor.memoryOverhead가 6GB 인 Yarn의 Spark 응용 프로그램을 실행 중입니다.

응용 프로그램의 실제 메모리가 증가하고 마침내 노드 관리자에 의해 종료되는 것을보고 있습니다.

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"를 무시하고 실제 메모리 사용이 40GB까지 증가한 것을 확인했습니다.

/ proc / pid / smaps에있는 전체 RSS를 확인한 결과, Yarn에 의해보고 된 실제 메모리와 동일한 값이었고 최상위 명령에 표시되었습니다.

나는 그것이 힙에 문제가 없다는 것을 확인했지만, 어떤 것이 힙 / 네이티브 메모리에서 증가하고있다. Visual VM과 같은 도구를 사용했지만 그곳에서 증가하는 것을 찾지 못했습니다. MaxDirectMmeory 또한 600MB를 초과하지 않았습니다. 활성 스레드의 최대 개수는 70-80이고 스레드 스택 크기는 100MB를 초과하지 않았습니다. MetaspaceSize는 약 60-70MB였습니다.

참고로 저는 Spark 1.2와 Hadoop 2.4.0을 사용 중이며 Spark 애플리케이션은 Spark SQL을 기반으로하고 있으며 Spark SQL의 메모리 내 캐싱에서 HDFS 읽기 / 쓰기 집약적 인 애플리케이션이며 데이터를 캐시합니다.

어디에서 메모리 누수를 디버그해야합니까? 아니면 이미 거기에 도구가 있습니까?

해결법

1. ==============================

   1.마침내 나는이 문제를 없앨 수 있었다. 문제는 Spark SQL의 마루 쓰기 경로에서 생성 된 압축기가 재활용되지 않아서 집행자가 모든 쪽모 세공 파일에 대해 새로운 압축기를 생성하여 실제 메모리 제한을 소모한다는 것입니다.

   마침내 나는이 문제를 없앨 수 있었다. 문제는 Spark SQL의 마루 쓰기 경로에서 생성 된 압축기가 재활용되지 않아서 집행자가 모든 쪽모 세공 파일에 대해 새로운 압축기를 생성하여 실제 메모리 제한을 소모한다는 것입니다.

   나는 Parquet Jira에서 다음과 같은 버그를 열었고 같은 것을 위해 PR을 올렸다.

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

   이로 인해서 메모리 문제가 해결되었습니다.

   추신 -이 문제는 나무 마루 쓰기 집중적 인 응용에서만 볼 수 있습니다.

from https://stackoverflow.com/questions/31646679/ever-increasing-physical-memory-for-a-spark-application-in-yarn by cc-by-sa and MIT license