문제 설명 및 분석
제목 문제는 일반적으로 설명 될 수 있습니다 :
실행기 드라이버에 하트 비트를 전송하는 시간이 없기 때문에, 드라이버가 실행 프로그램이 중단 된 것으로 판정하고, 이번에는 드라이버에 다른 태스크의 실행에 송신한다 재실행 실행 프로그램을 실행 프로그램;
Spark.network.timeout 긴 대기 시간 기본에 대한 120S를 =
아마 다음과 같은 오류를 완료
17/01/13 9시 13분 8초는 spark.HeartbeatReceiver을 WARN : 없음 최근 하트 비트와 집행자 5 제거 : 161684 MS는 120,000 시간 제한 초과 MS : 17/01/13 9시 13분 8초 오류 cluster.YarnClusterScheduler 분실 집행 5 slave10에 : 실행기 하트 비트는 161,684 초과 후 MS : 9시 13분 8초가 scheduler.TaskSetManager 경고 17/01/13 잃어버린 태스크 0.0 의 단계 0.0 (TID 0 slave10) ExecutorLostFailure 이유 (실행기 (5)가 실행하는 작업 중 하나에 의해 야기 종료) 집행 인 하트 비트 161684 후 시간 초과 MS 17/01/13 9시 13분 8초 정보 scheduler.DAGScheduler : 집행자가 손실 : 5 (신기원 0) 17/01/13 9시 13분 8초 정보 cluster.YarnClusterSchedulerBackend : (집행을 죽일 요청 S) (5) 17/01/13 9시 13분 8초 INFO scheduler.TaskSetManager : 0.1 태스크를 시작 으로 단계 0.0 (TID 5 slave06, 파티션 0 RACK_LOCAL, 8029 바이트) 17/01/13 9시 13분 8초 INFO storage.BlockManagerMasterEndpoint : 집행자 (5)을 제거하기 위해 노력 에서 BlockManagerMaster. 17/01/13 9시 13분 8초 INFO storage.BlockManagerMasterEndpoint : 분리 블록 BlockManagerId 매니저 (5 slave10, 34,439 ) 17/01/13 9시 13분 8초 INFO storage.BlockManagerMaster : 삭제됨 5 성공적 에 removeExecutor 17 / 01 / 13 9시 13분 8초 정보 scheduler.DAGScheduler : 호스트의 용액 에 손실 목록 이전 : slave10 5 드라이버 집행자 (들)을 죽이고 요청 : 17/01/13 9시 13분 8초 정보 yarn.ApplicationMaster $ AMEndpoint은. 17/01/13 9시 13분 8초 INFO scheduler.TaskSetManager : 0.1 완료된 태스크 의 단계 0.0 (TID 5) 에 slave06에 367 밀리 초 (5/5 ) 17/01/13 9시 13분 8초 INFO scheduler.DAGScheduler : ResultStage 0 (DataFrameFunctions.scala에서 saveAsNewAPIHadoopFile : 55) 완료 에서 162.495의
집행자는 드라이버에 하트 비트를 전송 할 시간 없다, 이유가 될 수있다
1. 정말 정지
때문에 충돌 원인 자원의 부족으로 작업을 수행합니다
3. 다른 이유
우리는 두 번째 주요 해결
솔루션
추가 리소스 --- 증가 memoryOverhead
설명 할 간단한
spark.yarn.executor.memoryOverhead 메모리는 JVM의 메모리 관리의 관점에서 방출, 높은 메모리 활용, [부족, 응용 프로그램의 시간, 스파크를 관리하기 위해 자신의 관리 메커니즘을 텅스텐, 낮은 효율 GC 만이 관리기구]
좋은 효율이 낮은와 spark.executor.memory 메모리는 가비지 수집 메커니즘의 다양성을 포함하는 상기 JVM, 유통, 재활용에 의해 관리되고
원인 분석
RDD의 저장 공간 부족이 다음 스토리지 파티션 후 RDD RDD 전에 파티션을 적용 할 경우, RDD이 필요 다시 계산하기 위해 파티션을 잃었 사용하는 경우, 이전 RDD의 손실의 결과;
영구 세대 메모리 부족 자바 힙 경우 나, OOM 다양한 상황을 생성 할 것이다, 집행 인이 살해되고, 스파크는 컨테이너 작업 실행자, 실패한 작업을 위해 다시 적용됩니다 또는 손실 된 데이터는 다시 실행이 executor에있을 것입니다;
실제 동작 용기 용량보다 ExecutorMemory + MemoryOverhead 합계 (총 메모리 JVM 프로세스) 얀 직접 컨테이너를 죽일 경우, 기록 실행기 로그가 없을 것, 불꽃은 용기 동작 실행기 재 적용된다;
이상 자바 힙 메모리 이외의 JVM 프로세스, 당신은 MemoryOverhead에게 충분한을 설정해야하는 경우, 그렇지 않으면 집행 살해됩니다
특정 작업
기본 구성은 M 단위 spark.yarn.executor.memoryOverhead 맥스 (executorMemory * 0.10, 384), 인
우리는 수동으로 설정할 수 있습니다
--conf spark.yarn.executor.memoryOverhead = 512
--conf spark.yarn.driver.memoryOverhead = 512
자원 소비를 감소 --- 사용 combineByKey
reduceByKey으로, 효율적으로 메모리 사용량을 줄일 수 있습니다
rdd.repartition (20 ) .MAP (에는 myMap) .groupBy (MyGroup을) .mapValues 발 .collect () rdd.repartition ( 20) .MAP (내지도) .MAP (MyGroup을) .reduceByKey ( 람다 X, Y, X + Y) .collect ()
여러 상대적으로 간단한 방법이있다
1. 증가 대기 긴 spark.network.timeout
같은 자원의 경우 2. 각 작업에 충분한 메모리가 있는지 확인하기 위해, 어쨌든, 동일의 총이다, 그렇게 생각하는, 집행 코어를 증가 집행의 수를 줄일 실행 프로그램 메모리를 증가
참고 :
https://blog.csdn.net/gangchengzhong/article/details/76474129
https://www.cnblogs.com/RichardYD/p/6281745.html 스파크 실 작업 분석의 이유 집행 인 이유 시간 제한
http://f.dataguru.cn/thread-906602-1-1.html spark.yarn.executor.memoryOverhead