Amazon EMR의 Spark에서 "Container killed on request. Exit code is 137" 오류를 해결하려면 어떻게 해야 하나요?

간략한 설명

컨테이너(Spark 실행기)의 메모리가 부족하면 YARN이 자동으로 종료합니다. 이로 인해 "Container killed on request. Exit code is 137" 오류가 발생했습니다. 이러한 오류는 좁은 변환과 넓은 변환 모두의 다양한 작업 단계에서 발생할 수 있습니다. 또한 YARN 컨테이너는 OS의 메모리가 부족한 경우, OS oom_reaper에 의해 종료되어 "Container killed on request. Exit code is 137" 오류가 발생했습니다.

해결 방법

다음 방법 중 하나 이상을 사용하여 "Exit status: 137" 스테이지 실패를 해결하세요.

드라이버 또는 실행기 메모리 늘리기

spark.executor.memory 또는 spark.driver.memory 파라미터를 전환하여 컨테이너 메모리를 늘립니다(오류의 원인이 된 컨테이너에 따라 다름).

실행 중인 클러스터에서:

프라이머리 노드에서 spark-defaults.conf를 수정합니다. 예시:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.memory 10g
spark.driver.memory 10g

단일 작업:

spark-submit를 실행할 때 --executor-memory 또는 --driver-memory 옵션을 사용하여 메모리를 늘립니다. 예시:

spark-submit --executor-memory 10g --driver-memory 10g ...

Spark 파티션 추가

컨테이너 메모리를 늘릴 수 없는 경우(예: 노드에서 maximizeResourceAllocation을 사용하는 경우), Spark 파티션의 수를 늘립니다. 이를 통해, 단일 Spark 작업에서 처리하는 데이터의 양이 줄어들어 단일 실행자가 사용하는 전체 메모리가 감소합니다. 다음 Scala 코드를 사용하여 Spark 파티션을 추가할 수 있습니다.

val numPartitions = 500
val newDF = df.repartition(numPartitions)

셔플 파티션의 수 늘리기

대규모 변환(예: join 또는 groupBy) 중에 오류가 발생하면 셔플 파티션을 추가합니다. 기본값은 200입니다.

실행 중인 클러스터에서:

프라이머리 노드에서 spark-defaults.conf를 수정합니다. 예시:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.sql.shuffle.partitions 500

단일 작업:

spark-submit를 실행할 때 --conf spark.sql.shuffle.partitions 옵션을 사용하여 셔플 파티션을 추가합니다. 예시:

spark-submit --conf spark.sql.shuffle.partitions=500 ...

실행기 코어의 수 줄이기

실행기 코어의 수를 줄이면 실행기가 동시에 처리하는 최대 작업의 수가 감소합니다. 이렇게 하면 컨테이너에서 사용하는 메모리 양이 줄어듭니다.

실행 중인 클러스터에서:

프라이머리 노드에서 spark-defaults.conf를 수정합니다. 예시:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.cores  1

단일 작업:

spark-submit을 실행할 때, --executor-cores 옵션을 사용하여 실행기 코어의 수를 줄입니다. 예시:

spark-submit --executor-cores 1 ...

인스턴스 크기 늘리기

또한 YARN 컨테이너는 OS의 메모리가 부족한 경우, OS oom_reaper에 의해 종료될 수 있습니다. oom_reaper로 인해 이 오류가 발생하는 경우, RAM이 더 많은 더 큰 인스턴스를 사용합니다. yarn.nodemanager.resource.memory-mb를 줄여 YARN 컨테이너가 Amazon EC2의 RAM을 모두 사용하지 않게 할 수도 있습니다.

dmesg 명령 출력에 대한 Amazon EMR 인스턴스 로그를 검토하여 오류가 oom_reaper로 인한 것인지를 확인할 수 있습니다. 먼저 종료된 YARN 컨테이너가 실행되고 있던 코어 또는 태스크 노드를 찾습니다. YARN Resource Manager UI 또는 로그를 사용하여 이 정보를 찾을 수 있습니다. 그런 다음, 컨테이너가 종료되기 전과 후에 이 노드의 Amazon EMR 인스턴스 상태 로그를 확인하여 프로세스가 종료된 원인을 확인합니다.

다음 예제에서는 YARN container_165487060318_0001_01_000244에 해당하는 ID 36787의 프로세스가 커널(Linux OOM이 종료된 원인)에 의해 종료되었습니다.

# hows the kernel looking
dmesg | tail -n 25

[ 3910.032284] Out of memory: Kill process 36787 (java) score 96 or sacrifice child
[ 3910.043627] Killed process 36787 (java) total-vm:15864568kB, anon-rss:13876204kB, file-rss:0kB, shmem-rss:0kB
[ 3910.748373] oom_reaper: reaped process 36787 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

관련 정보

Amazon EMR의 Spark에서 "Container killed by YARN for exceeding memory limits" 오류를 해결하려면 어떻게 해야 하나요?

Amazon EMR의 Spark 작업에서 스테이지 실패를 해결하려면 어떻게 해야 하나요?