복붙노트

[HADOOP] EMR에 열린 파일이 너무 많습니다.

HADOOP

EMR에 열린 파일이 너무 많습니다.

내 감속기에서 다음과 같은 예외가 발생합니다.

EMFILE: Too many open files
    at org.apache.hadoop.io.nativeio.NativeIO.open(Native Method)
    at org.apache.hadoop.io.SecureIOUtils.createForWrite(SecureIOUtils.java:161)
    at org.apache.hadoop.mapred.TaskLog.writeToIndexFile(TaskLog.java:296)
    at org.apache.hadoop.mapred.TaskLog.syncLogs(TaskLog.java:369)
    at org.apache.hadoop.mapred.Child$4.run(Child.java:257)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:396)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059)
    at org.apache.hadoop.mapred.Child.main(Child.java:249)

감속기 당 약 10,000 개의 파일이 생성됩니다. 각 상자의 ulimit을 설정할 수있는 방법이 있습니까?

부트 스트랩 스크립트로 다음 명령을 사용해 보았습니다. ulimit -n 1000000

그러나 이것은 전혀 도움이되지 못했습니다.

또한 /usr/lib/hadoop/hadoop-daemon.sh의 ulimit 명령을 대체하기 위해 부트 스트랩 작업에서 다음을 시도했습니다.

#!/bin/bash
set -e -x
sudo sed -i -e "/^ulimit /s|.*|ulimit -n 134217728|" /usr/lib/hadoop/hadoop-daemon.sh

그러나 우리가 마스터 노드에 로그인 할 때도 ulimit -n은 32768을 반환한다는 것을 알 수 있습니다. 또한 /usr/lib/hadoop/hadoop-daemon.sh에서 원하는 변경 사항이 있었고 ulimit -n 134217728을 가지고 있음을 확인했습니다.

우리는 이것에 대해 어떤 구성을 가지고 있습니까? 아니면 이에 대한 해결 방법이 있습니까?

필자의 주요 목표는 각 레코드의 ID에 따라 레코드를 파일로 분할하는 것이며, 지금 당장 15 억 개의 레코드가 증가 할 수 있습니다.

이 데몬이 각 슬레이브에서 실행되기 전에이 파일을 편집하는 방법은 없습니까?

해결법

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

    1.그렇기 때문에 Amazon EMR의 설정에서 기본적으로 설정된 ulimit가 32768로 너무 많아서 어떤 작업이 이보다 더 필요한 경우 로직을 다시 방문해야합니다. 따라서 모든 파일을 s3에 직접 쓰는 대신 로컬로 쓴 다음 1024 개의 파일 일괄 처리로 s3으로 옮겼습니다. 이것은 너무 많은 열린 파일 문제를 해결했습니다.

    그렇기 때문에 Amazon EMR의 설정에서 기본적으로 설정된 ulimit가 32768로 너무 많아서 어떤 작업이 이보다 더 필요한 경우 로직을 다시 방문해야합니다. 따라서 모든 파일을 s3에 직접 쓰는 대신 로컬로 쓴 다음 1024 개의 파일 일괄 처리로 s3으로 옮겼습니다. 이것은 너무 많은 열린 파일 문제를 해결했습니다.

    아마도 파일 디스크립터가 s3에 쓰기 위해 열렸을 때 로컬 파일에 기록 될 때와 같이 해제되거나 닫히지 않았을 것이다. 이에 대한 더 나은 설명은 언제나 환영합니다.

  2. ==============================

    2.부트 스트랩 액션을 통해이를 수행 할 수있는 방법이있을 수 있습니다. 특히 미리 정의 된 액션 중 하나입니다. 미리 정의 된 스크립트가 작동하지 않는다면 커스텀 스크립트는 모든 리눅스 클러스터에서 일반적으로 할 수있는 모든 것을 할 수 있습니다. 하지만 처음에는 왜 많은 파일을 출력하는지 묻겠습니다. HDFS / Hadoop은 대용량 파일의 수를 줄이기 위해 최적화되었습니다. 일종의 색인 생성을 원한다면 다른 이름을 가진 원시 파일을 작성하는 것이 최선의 방법은 아닐 것입니다.

    부트 스트랩 액션을 통해이를 수행 할 수있는 방법이있을 수 있습니다. 특히 미리 정의 된 액션 중 하나입니다. 미리 정의 된 스크립트가 작동하지 않는다면 커스텀 스크립트는 모든 리눅스 클러스터에서 일반적으로 할 수있는 모든 것을 할 수 있습니다. 하지만 처음에는 왜 많은 파일을 출력하는지 묻겠습니다. HDFS / Hadoop은 대용량 파일의 수를 줄이기 위해 최적화되었습니다. 일종의 색인 생성을 원한다면 다른 이름을 가진 원시 파일을 작성하는 것이 최선의 방법은 아닐 것입니다.

  3. ==============================

    3.나는이 문제를 가지고 있었지만 리눅스 환경이다.

    나는이 문제를 가지고 있었지만 리눅스 환경이다.

    여기로 이동하여 다음 단계를 수행하십시오.

    http://www.cyberciti.biz/faq/linux-unix-nginx-too-many-open-files/

  4. ==============================

    4.여기 올바른 해결책은 하나의 시퀀스 파일을 갖는 것인데,이 파일의 내용은 각각의 바이너리 파일이며, 파일 이름으로되어 있습니다. 레코드를 파일로 분리하는 것은 좋지만 파일을 하나의 큰 시퀀스 파일에 파일 이름으로 묶어 넣는 방울로 저장할 수 있습니다.

    여기 올바른 해결책은 하나의 시퀀스 파일을 갖는 것인데,이 파일의 내용은 각각의 바이너리 파일이며, 파일 이름으로되어 있습니다. 레코드를 파일로 분리하는 것은 좋지만 파일을 하나의 큰 시퀀스 파일에 파일 이름으로 묶어 넣는 방울로 저장할 수 있습니다.

  5. from https://stackoverflow.com/questions/12953251/too-many-open-files-in-emr by cc-by-sa and MIT license