Hadoop - HDFS 성능 에 큰 영향 을 미 치 는 킬러 - 셸

Hadoop 을 테스트 할 때 NameNode 에 있 는 dfshealth. jsp 관리 페이지 를 사용 하면 DataNode 가 실행 되 는 과정 에서 Last Contact 인자 가 항상 3 을 초과 하 는 것 을 발견 할 수 있 습 니 다.LC (Last Contact) 는 DataNode 가 네 임 노드 에 심장 박동 팩 을 보 내지 않 은 지 몇 초 되 었 는 지 를 보 여 주 는 것 이다.그러나 기본 DataNode 는 3 초 에 한 번 보 내 는 것 입 니 다. NameNode 는 기본적으로 10 분 을 DN 의 사망 시간 초과 시간 으로 합 니 다. 그러면 도대체 어떤 요소 가 JSP 관리 페이지 의 LC 파라미터 가 3 을 초과 하고 심지어 200 이상 에 이 를 수 있 는 지 알 고 있 습 니 다. 이런 상황 이 우리 시스템 의 안정 적 인 운행 에 영향 을 미 칠 수 있 습 니까?
사실 이 현상 을 제 가 한참 동안 관찰 했 는데 LC 파라미터 의 증가 에 영향 을 주 는 원인 은 다음 과 같은 몇 가지 가 있 습 니 다.
1. HDFS 는 BLOCK 를 대량으로 삭제 하 라 는 명령 을 받 았 습 니 다. 참고 하 십시오:https://issues.apache.org/jira/browse/HDFS-611;
2. HDFS 에 대량의 BLOCK 가 NN 에 게 보고 해 야 합 니 다.
3. 심장 박동 가방 의 데 이 터 를 조직한다.
4. 네트워크 환경.
앞의 두 가지 경우 LC 의 값 은 일반적으로 100 을 넘 지 않 아 성능 에 큰 영향 을 미 치지 않 는 다.Hadoop - 0.22.0 이후 버 전, Hadoop 도 개선 됐다.
그러면 값 의 하 나 는 DN 이 심장 박동 패 키 지 를 조직 하 는 동안 FSDataset 인터페이스 인터페이스 에 대해 관련 방법 을 호출 한 것 입 니 다. 구체 적 으로 FSDatasetMBean 인터페이스 중의 몇 가지 방법 을 참고 할 수 있 습 니 다.

/**
   * Returns the total space (in bytes) used by dfs datanode
   * @return  the total space used by dfs datanode
   * @throws IOException
   */  
  public long getDfsUsed() throws IOException;
    
  /**
   * Returns total capacity (in bytes) of storage (used and unused)
   * @return  total capacity of storage (used and unused)
   * @throws IOException
   */
  public long getCapacity() throws IOException;

  /**
   * Returns the amount of free storage space (in bytes)
   * @return The amount of free storage space
   * @throws IOException
   */
  public long getRemaining() throws IOException;

이 세 가지 방법 은 모두 가 잘 알 고 있 습 니 다. 그들의 실현 자 는 각각 DF, DU 두 가지 유형 입 니 다. 그들 은 비정 기적 으로 Shell 류 의 runComamnd 방법 을 통 해 시스템 명령 을 실행 하여 현재 디 렉 터 리 의 df, du 값 을 가 져 옵 니 다.
그러나 수행 하 는 과정 에서 재 미 있 는 일이 발생 했다. 필 자 는 13 개의 구역 이 있 고 모두 14 만 여 개의 BLOCK 가 저장 되 어 있다.
Df 와 du 는 평균 2 초 이상 실행 되 는데, 극 적 으로 DU 와 DF 가 가장 높 은 것 은 한 파 티 션 디 렉 터 리 명령 을 수행 하 는 데 180 초 이상 이 걸 렸 다 는 것 이다.(Shell\# runCommand 방법 에서 ProcessBuilder 에서 process. start () 실행 시간 으로 예화 합 니 다.
파 티 션 디 렉 터 리 에 있 는 BLOCK 의 수가 너무 많아 서 실행 이 느 린 것 일 까요? Liux 시스템 에서 DF DU 와 같은 명령 을 실행 한 결 과 는 모두 밀리초 로 끝 납 니 다.그 문 제 는 분명히 ProcessBuilder 에 있 습 니 다. 이 문 제 는 JVM 이 Linux 커 널 을 통 해 fork 서브 프로 세 스 를 통 해 알 고 있 습 니 다. 하위 프로 세 스 는 당연히 부모 프로 세 스 의 모든 메모리 핸들 을 완전히 계승 합 니 다. jstack 는 JVM 이 스 레 드 상태 가 대부분 WAITING 에 있 는 것 을 보 았 습 니 다. 이 과정 은 테스트 를 통 해 DFSClient 의 기록 시간 초과 나 스 트림 을 닫 는 데 영향 을 줄 수 있 습 니 다.(다음 편 에 서 는 오 랜 Running 의 DFSClient 로 서 흐름 의 닫 기 작업 을 잘 해 야 한다 고 말 했다. 0.21 - trunk 중류 의 닫 기 는 여전히 안전 위험 이 존재 한다.) 마지막 으로 나 는 32 개의 기계 에서 64 개의 기계 로 바 뀌 었 지만 문 제 는 여전히 존재 한다.
마지막 으로 HDFS 를 다시 시작 하여 DU, DF 및 자신의 IOStat, Uptime 클래스 를 재 구성 하여 Linux 시스템 을 통 해 실행 하고 결 과 를 임시 파일 에 출력 한 다음 Hadoop 에서 읽 을 수 밖 에 없 었 습 니 다. LC 문 제 는 더 이상 발생 하지 않 습 니 다.
본문 전재:http://dongyajun.javaeye.com/blog/627905