Linux에서 열린 파일 수가 제한되는 이유는 무엇입니까?

136

지금은 방법을 알고 있습니다.

프로세스 당 열린 파일 제한 찾기 : ulimit -n
모든 프로세스별로 열린 파일을 모두 계산하십시오. lsof | wc -l
열린 파일의 최대 허용 개수를 얻습니다. cat /proc/sys/fs/file-max

내 질문은 : 왜 리눅스에서 열린 파일의 한계가 있습니까?

open-files limit

— 잔펑
소스

2

@Rob Googled는 약간 포크 포크 라는 것을 알고 있습니다. 열린 파일 제한을 설명하는 데 사용할 수 있습니까?

— xanpeng

6

프로세스 제한과 파일 제한은 중요하므로 포크 폭탄과 같은 것은 모든 사용자의 서버 / 컴퓨터를 파괴하지 않으며 일시적으로 만 사용하는 사용자 만 서버 / 컴퓨터를 손상시키지 않습니다. 그렇지 않으면 공유 서버에있는 누군가가 폭격을 시작하여 자신뿐만 아니라 모든 사용자를 위해 완전히 무너 뜨릴 수 있습니다.

— Rob

3

매우 유용한 명령을 요약 한 것이 좋습니다! : +1 :

— Joshua Pinter

7

@Rob, 포크 폭탄은 파일 제한이 프로세스 당이므로 포크 폭탄과 관련이 없으며 포크 할 때마다 새 파일 핸들을 열지 않습니다.

— psusi

86

그 이유는 운영 체제에 열려있는 각 파일을 관리하기 위해 메모리가 필요하고 메모리는 특히 임베디드 시스템에서 제한된 리소스이기 때문입니다.

루트 사용자는 프로세스 당 ( ulimit -n) 및 시스템 당 (예 :) 최대 열린 파일 수를 변경할 수 있습니다 echo 800000 > /proc/sys/fs/file-max.

— 조펠
소스

21

보안상의 이유도 있습니다. 제한이 없다면, 유저 랜드 소프트웨어는 서버가 다운 될 때까지 끝없이 파일을 만들 수 있습니다.

— Coren

15

@Coren 여기서 논의 된 한계는 열린 파일 핸들러 수에 대해서만 적용됩니다. 프로그램은 파일 핸들러를 닫을 수 있으므로 사용 가능한 모든 디스크 공간이 가득 찰 때까지 많은 파일을 원하는만큼 만들 수 있습니다. 이를 방지하기 위해 디스크 할당량 또는 분리 된 파티션을 사용할 수 있습니다. 보안의 한 측면이 리소스 고갈을 방지하고 있다는 점에서 의미가 있습니다. 여기에는 한계가 있습니다.

— jofel

1

@jofel 감사합니다. 열린 파일 핸들은 struct file의 인스턴스로 표시 되며이 구조체의 크기는 매우 작습니다 (바이트 수준). /.../file-max메모리가 사용되지 않는 한 상당히 큰 값으로 설정할 수 있습니까?

— xanpeng

7

@xanpeng 나는 커널 전문가는 아니지만, 내가 볼 수있는 한, 기본값은 file-maxRAM 크기를 10k로 나눈 것 같습니다. 파일 핸들러 당 사용 된 실제 메모리는 훨씬 작아야하고 ( struct file드라이버 종속 메모리 크기 와 크기 ) 상당히 보수적 인 한계로 보입니다.

— jofel

63

lsof | wc -l많은 중복 항목 을 요약합니다 (포크 된 프로세스는 파일 핸들 등을 공유 할 수 있음). 이 수는에 설정된 제한보다 훨씬 높을 수 있습니다 /proc/sys/fs/file-max.

Linux 커널의 관점에서 현재 열린 파일 수를 얻으려면 다음을 수행하십시오.

cat /proc/sys/fs/file-nr

예 :이 서버는 열린 파일 수가 최대 65536 개 중 40096 개이지만 lsof는 훨씬 더 많은 수를보고합니다.

# cat /proc/sys/fs/file-max
65536
# cat /proc/sys/fs/file-nr 
40096   0       65536
# lsof | wc -l
521504

— 그렙 네케
소스

1

와 같이 lsof많은 파일을 두 번 이상보고 /dev/null할 수 있으므로 다음 과 같이 최선의 추측을 시도 할 수 있습니다.lsof|awk '{print $9}'|sort|uniq|wc -l

— Yvan

lsof|awk '!a[$NF]++{c++}END{print c}'중복되지 않은 열린 파일 수를 얻는 데 사용할 수 있습니다 .

— P ....

18

나는 그것이 역사적 이유로 크게 생각합니다.

유닉스 파일 디스크립터는 작은, int같은 함수에 의해 리턴 된 값 open과 creat, 그리고 통과에 read, write, close, 등.

적어도 유닉스 초기 버전에서 파일 디스크립터는 단순히 고정 크기 프로세스 단위의 구조 배열에 대한 색인 일 뿐이며, 각 구조에는 열린 파일에 대한 정보가 들어 있습니다. 올바르게 기억한다면 일부 초기 시스템은이 테이블의 크기를 20 정도로 제한했습니다.

더 현대적인 시스템에는 더 높은 한계가 있지만 동일한 일반 체계를 크게 관성에서 벗어났습니다.

— 키이스 톰슨
소스

1

C 언어 FILE 데이터 구조에 대한 Solaris 제한은 20입니다. 파일 핸들 수가 항상 많았습니다.

— Lothar

@Lothar : 흥미 롭습니다. 한계가 왜 다른지 궁금합니다. fileno및 fdopen기능을 감안할 때 거의 상호 교환 가능할 것으로 기대합니다.

— Keith Thompson

유닉스 파일은 단순히 파일 핸들 (int)이 반환 한 것 이상입니다. 디스크 버퍼와 현재 파일 오프셋, 파일 소유자, 권한, inode 등을 정의하는 파일 제어 블록이 있습니다.

— ChuckCottrill

@ChuckCottrill : 물론입니다. 그러나 대부분의 정보는 파일이 int디스크립터 또는를 통해 액세스되는지 여부에 관계없이 저장되어야 합니다 FILE*. 당신은을 통해 열린 20 개 이상의 파일이있는 경우 open(), 것입니다 fdopen()실패?

— 키이스 톰슨