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

10

Linux에서 열린 파일의 최대 수를 구성 할 수있는 크기 (기술적 또는 실용적인)에 제한이 있습니까? 매우 큰 숫자 (예 : 1-100M)로 구성하면 몇 가지 부작용이 있습니까?

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

— 삼포
소스

이론적으로, 사용 가능한 메모리와 각 fd가 1K의 메모리를 소비한다는 주장에 따라 시스템에서 처리 할 수있는 파일 설명자 수를 계산할 수 있습니다. serverfault.com/questions/330795/…

— Alastair McCormack

10

제한의 주된 이유는 과도한 메모리 소비를 피하는 것입니다 (각 열린 파일 설명자는 커널 메모리를 사용합니다). 또한 파일 디스크립터가 누출되고 시스템 리소스를 소비하는 버그가있는 응용 프로그램을 보호합니다.

그러나 10 년 전의 시스템과 비교했을 때 RAM 현대 시스템이 얼마나 많은지를 감안할 때 오늘날 기본값은 상당히 낮습니다.

2011 년 Linux에서 파일 디스크립터의 기본 하드 한계 는 1024에서 4096 으로 증가했습니다 .

일부 소프트웨어 (예 : MongoDB)는 기본 제한보다 더 많은 파일 설명자를 사용합니다. MongoDB 직원 은이 제한을 64,000으로 올리는 것이 좋습니다 . rlimit_nofile특정 응용 프로그램에 300,000을 사용했습니다 .

소프트 한계를 기본값 (1024)으로 유지하는 한 하드 한계를 늘리는 것이 안전합니다. setrlimit()한계를 소프트 한계 이상으로 높이려면 프로그램을 호출해야하며 여전히 하드 한계에 의해 제한됩니다.

관련 질문도 참조하십시오.

— AB
소스

6

이것은 실제로 질문에 대답하지 않았지만, 하드 한계를 설정할 수있는 방법 에 대한 기술적 또는 실제적인 한계 가 있는지 물었 습니다 . 있습니다 만,이 답변에서는 전혀 언급하지 않습니다.

— JdeBP

나는 약 1 백만을 넘어 한계를 높이는 것이 불가능하다는 것을 알았습니다. 많은 구성을 변경 하더라도이 이상으로 올릴 수 없기 때문에 커널에서 하드 코딩 될 수 있다고 생각합니다. superuser.com/questions/1468436/…

— Pavel Komarov

3

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

이러한 제한은 사용자를 자신의 (또는 제 3 자) 실수로부터 보호하는 이점이 있습니다. 예를 들어, 무기한 포크를하는 작은 프로그램이나 스크립트를 실행하면 결국 하나의 프로그램을 ulimit차단하여 더 강렬한 (복구 할 수없는) 컴퓨터 정지를 방지합니다.

이러한 제한을 늘려야 할 정확한 이유가 없다면이를 피하고 더 잘 수면을 취해야합니다.

— 줄리 펠티에
소스

2

기술적으로 부호없는 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 */
};

— 레너드 T
소스

2

이것에 대한 언급이 있습니까?

— Tim

또한, 32 비트의 최대 값의 그 서명 정수, 부호없는 32 비트 정수의 최대 값은 4294967295입니다.

— Sampo

맞아, 삼포 내 실수.

— Leonard T

0

나는 당신의 우려가 이해할 만하다고 생각하지만 대부분의 리눅스는 구성을 위해 많은 메모리를 소비하지 않을 것입니다 (그러나 파일 설명자를 사용하지는 않습니다) :)

지난 10 년간 프로 경력에서 그런 문제를 기억할 수 없습니다.

문안 인사.

— 팀 코너
소스

0

조용히 늦었지만 다른 사람이이 질문에 대한 답을 얻는 데 도움이됩니다. 리눅스에서 열린 파일 수에 대한 실제 제한은 프로세스가 열 수있는 최대 파일 설명자 수를 사용하여 계산할 수도 있습니다.

시스템에서 시스템으로 한계가 변경되는 것을 보았습니다. 로부터 getlimit의 man 페이지 당신은 볼 수 있습니다 RLIMIT_NOFILE-1내부적으로 지정을 제한합니다.

RLIMIT_NOFILE 값을 확인하려면 아래 명령문을 사용하여 튜플을 얻을 수 있습니다

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

튜플은 결과를 (Soflimit, hardlimit)로 반환합니다. 여러 시스템에서 실행하면 결과는 다음과 같습니다.

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos

참고 : 9223372036854775807이 숫자는 단순히 무한대를 의미합니다. 이 작업을 수행하기 전에 항상 다른 자원 제한에 도달합니다. 시스템의 하드 리미트를 원래 수준 이상으로 수정 한 경우 커널 매개 변수를 수정해야합니다.

— 안킷 쿨 카르 니
소스