1. 예외 설명
회사는 하이브 작업을 제출할 수 없다고 응답 한 다음 beeline에서 다음과 같은 간단한 테스트를 수행 한 결과 다음 프로세스에 갇혀 있음을 발견했습니다.
1), 첫 번째 쿼리 :이 쿼리의 애플리케이션 ID는 application_1600160921573_0026입니다.
select count(*) from co_ft_in_out_bus_dtl;
2), 두 번째 질의 :이 질의는 다음 과정에서 오랫동안 기다린 후 application_id를 생성하지 않았습니다.
select count(*) from xft_sheet1;
Beeline 출력이 다음 프로세스에서 멈춤
Submitting tokens for job: job_1600165270401_0014
INFO : Kind: HDFS_DELEGATION_TOKEN, Service: ha-hdfs:nameservice1, Ident: (token for hive: HDFS_DELEGATION_TOKEN owner=hive/[email protected], renewer=yarn, realUser=, issueDate=1600165500389, maxDate=1600770300389, sequenceNumber=20818157, masterKeyId=641)
3) 이때 pyspark의 실행도 느리지 만 대용량 파일을 HDFS에 올리는 시간은 클러스터의 이전 정상 상태와 크게 다르지 않아 HDFS가 느려지지 않았 음을 나타냅니다
. ResourceManager 차트를 사용하여 GC 표시
ResourceManager GC 시간은 문제가 발생했을 때 매우 길어서 9 초에 도달했습니다.
9 월 10 일 GC 시간도 매우 길어서 80 초에 이르렀지만 클러스터에 이상이없는 것으로 나타났다.
5) 당시 ResourceManager의 JVM이 많이 사용되지 않았는지 확인합니다.
ResourceManager의 JVM 사용량은 지난 7 일 동안 비교적 일정했으며 ResourceManager JVM에서 구성한 최대 4GB에 도달하지 않았습니다.
2. 이상 분석
1. 가능한 한 빨리 비즈니스를 복원하려면 ResourceManager를 여러 번 다시 시작했지만 예외를 해결할 수 없음을 발견했습니다. 따라서 ResourceManager 로그를 확인하고 이전 테스트에서 제출 한 application_1600160921573_0026의 문제를 해결하십시오. ResourceManager 로그에서 제출 된 작업이 복구를 반복하고 있음을 확인할 수 있습니다.
2020-09-15 18:09:46,009 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: Recovering app: application_1600162721525_0026 with 0 attempts and final state = NONE
...
2020-09-15 18:21:31,592 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: Recovering app: application_1600162721525_0026 with 0 attempts and final state = NONE
...
2020-09-15 18:33:44,648 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: Recovering app: application_1600162721525_0026 with 0 attempts and final state = NONE
...
2020-09-15 18:45:31,393 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: Recovering app: application_1600162721525_0026 with 0 attempts and final state = NONE
...
2020-09-15 18:55:21,618 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: Updating application application_1600162721525_0026 with final state: FAILED
2. 동시에 Active ResourceManager (cmsnn002) 로그에서 Zookeeper와 관련된 다음과 같은 오류를 확인할 수 있으며, 다음 로그를 통해 Zookeeper [2]의 비정상 연결로 인해 Active ResourceManager가 Standby 상태로 진입 한 것을 확인할 수 있습니다. ] :
2020-09-15 16:36:00,882 INFO org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore: Maxed out ZK retries. Giving up!
2020-09-15 16:36:00,882 INFO org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore: Watcher event type: None with state:Disconnected for path:null for Service org.apache.hadoop.yarn.server.resourcemanager.recovery.RMStateStore in state org.apache.hadoop.yarn.server.resourcemanager.recovery.RMStateStore: STARTED
2020-09-15 16:36:00,882 INFO org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore: ZKRMStateStore Session disconnected
2020-09-15 16:36:00,883 WARN org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Transitioning the resource manager to standby.
2020-09-15 16:36:00,921 INFO org.apache.hadoop.ipc.Server: Stopping server on 8032
3. 그러나 나쁜 점은 그날 16:36 경에 다른 ResourceManager (cmsnn001)가 Active 상태로 진입 할 수 없었던 것 같습니다 (그러나 관련 로그가 누락되어 구체적인 이유를 확인할 수는 없지만 또한 사육사의 손실로 인해 발생). 이로 인해 ResourceManager (cmsnn002)가 다시 활성 상태가되지만 10 분이 지났으며 이는 10 분 [3] 동안 ResourceManager 중단 시간과 동일하며 모든 작업을 제출할 수 없습니다.
2020-09-15 16:47:09,713 INFO org.apache.hadoop.ha.ActiveStandbyElector: Writing znode /yarn-leader-election/yarnRM/ActiveBreadCrumb to indicate that the local node is the most recent active...
2020-09-15 16:47:09,718 INFO org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Transitioning to active state
2020-09-15 16:47:22,879 INFO org.apache.hadoop.yarn.server.resourcemanager.RMAppManager: Recovering 10176 applications
4. 지난 9 월 10 일과 결합하여 ResourceManager의 GC 시간이 비정상적으로 증가하는 것을 보아 9 월 10 일 ResourceManager 로그와 결합하여보다 효과적인 정보를 추출해 보았습니다. 9 월 15 일에 문제가 발생했을 때와 9 월 10 일에 ResourceManager GC 시간이 비정상적으로 증가한 경우 ResourceManager의 로그를 확인하여 다음 예외 [4]를 발견했습니다.이 예외는 ResourceManager가 Zookeeper와 연결을 설정하려고했지만 을 통해 1000 회 (1-1000) 번 후에도 여전히 Zookeeper와 연결을 설정할 수 없으므로 각 Zookeeper 노드는 무한 루프 연결에 들어갑니다.
5. 따라서 Zookeeper 로그를 확인하고 ResourceManager가 항상 Zookeeper에 연결할 수없는 이유를 찾으십시오. 사육사 로그에서 문제 발생시 다음과 같은 비정상적인 정보가 발견되었습니다 [5].
2020-09-15 16:25:43,431 WARN org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of session 0x17187f84f281336 due to java.io.IOException: Len error 14307055
6. 정보 검색을 통해 Cloudera의 공식 웹 사이트에 Zookeeper [6]에서 유사한 문제를 언급하는 Knowledge Base가 있는데, 이는 Zookeeper의 Jute Max Buffer 매개 변수 구성 크기와 관련이 있다고합니다.
https://my.cloudera.com/knowledge/Active-ResourceManager-Crashes-while-Executing-a-ZooKeeper?id=75670
7．Knowledge Base의 도입을 통해 현재 클러스터에서 Zookeeper의 Jute Max Buffer 값이 4MB이고이 값이 기본적으로 4MB인지 확인하고 [7] Zookeeper에서 Len 오류 14307055 (≈14MB) 예외를 확인합니다. 로그는 클러스터의 Zookeeper가 승인 함을 나타냅니다.의 데이터 조각이 이미 기본 4MB보다 훨씬 커서 Zookeeper의로드가 증가합니다. 특정 순간에 Active ResourceManager가 Zookeeper에서 연결 해제 된 후 더 이상 다시 연결할 수 없습니다.
3. 예외 해결
1. 아래 단계에 따라 Zookeeper의 Jute Max Buffer 값을 기본값 4MB에서 32MB로 늘립니다.
1) Cloudera Manager> Zookeeper> 구성을 엽니 다.
2) Jute Max Buffer를 검색하고 jute.maxbuffer의 값을 4MB에서 32MB로 수정합니다.
3) 설정을 저장하고 지속적으로 Zookeeper 서비스를 다시 시작하십시오.
2. 다시 beeline 테스트에서 모든 작업을 정상적으로 제출할 수있는 것으로 나타 났으며, 이전에 보류중인 애플리케이션은 점차적으로 작동을 재개하고 보류중인 컨테이너가 점차 감소하여 지금까지 문제가 해결되었습니다.
4. 문제 요약
1.이 실패의 원인은 Zookeeper의 jute.maxbuffer가 오버플로되어 Zookeeper 서버에 오류를 일으켜 ResourceManager [1]와의 연결을 끊었 기 때문에 당시 클러스터로드와 관련이 있습니다. Len 오류는 ResourceManager에 의해 전송되지 않지만 Zookeeper가 ResourceManager로 반환하려는 데이터 양이 기본 4MB 제한을 초과하기 때문에 Zookeeper Server 측에서 오류가 발생합니다. 특정 데이터 양은 현재 상황과 관련이 있어야합니다. 해당 Znode의.
2020-09-15 16:25:43,431 WARN org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of session 0x17187f84f281336 due to java.io.IOException: Len error 14307055
2. 일반적으로이 문제는 실행중인 작업 수, 작업 시도 횟수, 응용 프로그램로드 증가 및 클러스터 확장과 관련이있을 수 있습니다. 이 문제의 시간을 확인하고 9 월 10 일에 YARN에는 보류중인 컨테이너가 70,000 개가 넘습니다 [2]. 이는 당시 YARN 및 Zookeeper의 부하에 비해 상대적으로 큰데, 이는 ResourceManager와 Zookeeper의 연결이 끊어진 이유이기도합니다. .
9 월 15 일에는 70,000 개 이상의 YARN 보류 컨테이너가있었습니다.
9 월 10 일에는 70,000 개 이상의 YARN 보류 컨테이너가있었습니다.
지난 30 일 동안 YARN 보류 컨테이너 :
3. 추가 조사를 통해이 결함으로 인한 Lenerror 예외는 실제로 Zookeeper (ZOOKEEPER-706) [1]의 버그로 인해 발생하는 것으로 확인되었습니다. YARN이 Zookeeper에 기록하는 데이터에는 응용 프로그램의 속성 정보뿐만 아니라 응용 프로그램의 delegationToken과 같은 런타임 정보와 각 시도의 진단 정보도 포함되어 있으므로 대용량 클러스터는 큰 데이터를 작성하기 쉽습니다. Zookeeper에 대한 데이터 양 YARN 이와 관련하여 중요한 수리가 이루어졌습니다. 자세한 내용은 YARN-3469, YARN-2962, YARN-7262, YARN-6967 [2]을 참조하십시오. 우리 클러스터는 CDH5.15.1입니다. 조사 결과 ResourceManager의이 문제는 CDH5에서 수정되지 않은 것으로 나타났습니다. CDH5에는 YARN-3469가 포함되어 있지만 근본적으로 해결하려면 최소한 YARN-2962, YARN-7262 및 YARN-이 필요합니다. 6967, znode의 구조를 최적화하여 많은 수의 znode 타일이 Zookeeper 서비스에서 Len 오류를 일으키는 것을 방지합니다. 이들 모두는 CDH6 및 후속 버전에 포함되었지만 CDH5에는 포함되지 않습니다. 또한 커뮤니티가 YARN을 개선했지만 YARN의 새로운 기능이 지속적으로 추가됨에 따라 Zookeeper의 스토리지 요구 사항도 증가하고 있습니다. CDH6로 업그레이드하더라도 YARN과 Zookeeper간에 많은 양의 데이터를 쓰는 데 여전히 문제가있을 수 있습니다. .
【1】
https://my.cloudera.com/knowledge/ERROR-javaioIOException-Len-errorquot-in-Zookeeper-causing?id=275334
https://issues.apache.org/jira/browse/ZOOKEEPER-706
【2】
https://issues.apache.org/jira/browse/YARN-3469
https://issues.apache.org/jira/browse/YARN-2962
https://issues.apache.org/jira/browse/YARN-7262
http://mail-archives.apache.org/mod_mbox/hadoop-yarn-issues/201708.mbox/%3CJIRA.13093146.1502193666000.123395.1502242800181@Atlassian.JIRA%3E
5. 결함 요약
- ResourceManager는 주로 Zookeeper에 연결하여 실행중인 모든 애플리케이션 및 시도를 포함하여 YARN 클러스터의 영구 상태를 저장하는 데 사용되는 State-store를 업데이트합니다. 이 상태 저장소는 Zookeeper의 / rmstore 디렉토리에 저장되며 zookeeper-client를 통해이 데이터에 액세스하고 읽을 수 있습니다. Zookeeper가 장애 조치되면 Active로 선택된 Zookeeper는 / rmstore의 데이터를 읽고 전체 YARN 클러스터의 실행 상태를 복원합니다.
2. 문제가 발생했을 때 두 개의 ResourceManager가 지속적으로 활성과 대기 사이를 전환하려고 시도했지만 ResourceManager가 Zookeeper의 응답을 기다리지 않았기 때문에 성공하지 못했습니다.
1) 특히 ACTIVE ResourceManager (cmsnn002)는 로그 org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore : Retrying operation on ZK. Retrying no. 999 in 로그를 통해 지속적으로 Zookeeper 중 하나에 연결을 시도합니다. ResourceManager 중 하나가 첫 번째 Zookeeper에 1000 번 연결을 시도했지만 Zookeeper로부터 응답을받지 못한 후 계속해서 1에서 두 번째 Zookeeper에 연결을 시도했지만 여전히 응답을받지 못했습니다. 1000 번 후 두 번째 사육사 우리는 5 명의 사육사를 가지고 있으며, 5 명의 사육사에게 1000 개의 연결을 반복적으로 통과했지만 마침내 사육사로부터 응답을받지 못했습니다. 이 프로세스에서 ResourceManager를 롤링 다시 시작하려고 시도했지만 여전히 복구되지 않았습니다. 이는 작동 할 수없는 Zookeeper 상태에 연결하는 ACTIVE ResourceManager의 무한 루프와 동일합니다.
2) ResourceManager가 Zookeeper에서 데이터를 읽는 횟수는 기본적으로 각 Zookeeper에서 1,000 회이며, Zookeeper 데이터를 한 번만 읽어도 활성 / 대기 전환이 완료 될 수 있습니다. ResourceManager가 Zookeeper에서 데이터를 읽는 횟수를 제어하는 기본 매개 변수는 yarn.resourcemanager.zk-num-retries이고 각 읽기 시간을 제어하는 기본 매개 변수는 yarn.resourcemanager.zk-retry-interval-ms입니다. yarn-site.xml에 대한 CM의 ResourceManager 고급 구성 스 니펫 (안전 밸브)을 통해 구성을 수정할 수 있습니다. 그러나 ZOOKEEPER-706의 버그가 수정되지 않으면 ResourceManager가 Zookeeper에 연결되어 있어도 데이터를 읽을 수 없을 가능성이 있기 때문에이 두 값의 수정은이 결함에 도움이되지 않습니다.
3.이 실패에서 우리는 Zookeeper의 jute maxbuffer를 32MB로 변경하여이 문제를 해결했습니다. 이 값의 구성 크기와 관련하여 Zookeeper 로그에서 Len 오류의 최대 값을 찾을 수 있으며 32MB 미만인 경우 통합 권장 사항은 32MB입니다. 그러나이 값은 너무 크게 구성 할 수 없습니다. 결국 Zookeeper는 큰 조각 데이터 저장 소용으로 설계되지 않았습니다. 응용 프로그램 (또는 서비스)이 계속해서 많은 양의 데이터를 Zookeeper에 쓰면 디스크 간의 동기화에 압력이 가해집니다. 그리고 Zookeeper 자체에 의존하기 쉬우 며 Zookeeper의 애플리케이션 (서비스)이 불안정합니다. 예를 들어이 YARN 실패는 본질적으로 이러한 이유로 발생합니다.
4. 다음에이 문제가 다시 발생하면 CM-> Zookeeper 페이지에서 현재 Zookeeper Leader를 확인한 다음 Zookeeper 로그 디렉터리 (예 : / var / log / zookeeper /) 및 데이터 디렉터리 (예 : / var / lib / zookeeper / version-2) 디렉터리를 분석합니다. Zookeeper의 데이터 저장소를 분석 한 다음 어떤 데이터가 작성되어 Zookeeper Len 오류 문제가 발생하는지 추가로 결정할 수 있습니다. LogFormatter를 통해 사육사가 당시 작성한 데이터를 확인합니다. 구체적인 방법은 다음 링크 [1]을 참조하십시오.
【1】:http://www.openkb.info/2017/01/how-to-read-or-dump-zookeeper.html
1) Zookeeper 데이터는 먼저 데이터 디렉토리의 트랜잭션 로그 (예 : / var / lib / zookeeper / version-2)에 기록되고 총량이 100,000 개 레코드에 도달하면 스냅 샷이 자동으로 생성됩니다 [2]. 따라서 데이터 파일은 시간에 따라 저장되지 않으며 데이터 저장 날짜를 설정할 수 없습니다. CDH의 기본 설정은 매일이 디렉토리를 정리하고 5 개의 스냅 샷 만 유지하는 것입니다. 더 많은 데이터를 유지하려면 CM-> Zookeeper-> Configuration-> Auto Purge Snapshots Retain Count [3에서 더 많이 저장하도록 설정할 수 있습니다. ] Snapshots,하지만 이것은 Zookeeper로 인해 발생한 문제를 찾는 데별로 도움이되지 않을 수 있습니다. 스냅 샷이 생성되는 시간이 문제가 발생하는 시점이 아닐 수 있기 때문입니다. 따라서 문제가 반복 될 경우 전체 데이터 디렉토리를 다음 위치에 패키지화하는 것이 좋습니다. 분석을위한 시간.
【2】
【3】
