☰

Linux에서 허용되는 최대 열린 파일 수

tag-icon • tag-icon linux files limit open-files
Linux에서 허용되는 최대 열린 파일 수

Linux에서 구성할 수 있는 최대 열린 파일 수에 (기술적 또는 실제적) 제한이 있습니까? 구성이 큰 경우(예: 1-100M) 부작용이 있습니까?

여기서는 임베디드 시스템이 아닌 서버 사용을 생각하고 있습니다. 열린 파일을 많이 사용하는 프로그램은 물론 메모리를 소비하고 속도가 느려지지만 제한이 필요한 것보다 훨씬 크게 구성되면(예: 구성만으로 메모리가 소비됨) 부작용에 관심이 있습니다.

답변1

나는 이 제한의 주된 이유가 과도한 메모리 소비를 피하기 위한 것이라고 생각합니다(열려 있는 각 파일 설명자는 커널 메모리를 사용합니다). 또한 버그가 있는 응용 프로그램이 파일 설명자를 유출하고 시스템 리소스를 소모하는 것을 방지합니다.

하지만 현대 시스템의 RAM이 10년 전 시스템과 비교했을 때 얼마나 우스꽝스러운지 생각해 보면 오늘날의 기본값은 상당히 낮다고 생각합니다.

2011년부터 Linux의 파일 설명자에 대한 기본 하드 제한은 다음과 같습니다.1024에서 4096으로 증가.

MongoDB와 같은 일부 소프트웨어는 기본 제한보다 더 많은 파일 설명자를 사용합니다. 몽고DB 사람들이 한도를 64,000으로 늘리는 것이 좋습니다.. rlimit_nofile일부 응용 프로그램에서는 300,000을 사용했습니다.

소프트 제한을 기본값(1024)으로 유지하는 한 하드 제한을 높이는 것은 아마도 매우 안전할 것입니다. 프로그램은 setrlimit()제한을 소프트 제한 위로 올리도록 호출해야 하며 여전히 하드 제한에 의해 제한됩니다.

또한 몇 가지 관련 질문을 참조하십시오.

답변2

기술적으로는 unsigned long(C Lang)의 최대값인 4,294,967,295로 제한됩니다.

참조 fs.h문서

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

답변3

이 효과는 일반적으로 관찰할 수 없지만 커널의 IO 모듈은 이러한 모든 열린 파일 설명자를 처리해야 하며 캐시 효율성에도 영향을 미칠 수 있습니다.

이러한 제한은 사용자 자신(또는 제3자)의 오류로부터 사용자를 보호하는 이점이 있습니다. 예를 들어, 무한정 분기되는 작은 프로그램이나 스크립트를 실행하면 결국 그 중 하나가 차단되어 ulimit더 심각한(그리고 잠재적으로 복구 불가능한) 컴퓨터 정지를 방지할 수 있습니다.

이러한 제한을 늘려야 하는 명확한 이유가 없다면 그렇게 하지 말고 잠을 더 잘 자야 합니다.

답변4

귀하의 우려는 이해할 만하다고 생각하지만 Linux는 구성된(그러나 사용되지 않는 파일 설명자)에 대해 많은 메모리를 소비하지 않을 가능성이 높습니다. :)

나는 지난 10년 동안 내 경력에서 이런 문제가 발생한 기억이 없습니다.

인사.

관련 정보