파일 설명자 제한(ulimit -n)의 역사적 이유는 무엇입니까?

@patbarron은 아직 자신의 의견을 답변으로 게시하지 않았으며 정말 훌륭합니다. 답을 찾는 사람이 있다면 여기 있습니다.

그가 썼다:

예를 들어 7판의 소스 코드를 볼 수 있습니다(minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/h/user.h) 원래 어떻게 구현되었는지 확인하세요. "NOFILE"은 프로세스당 최대 열린 파일 수로, 각 프로세스가 할당하는 데이터 구조의 크기에 영향을 미칩니다. 이러한 구조는 실제로 사용되는지 여부에 관계없이 메모리를 차지합니다. 다시 말하지만, 이는 더 이상 수행되지 않기 때문에 대부분 역사적으로 흥미롭지만, 이는 그 기원에 대한 추가적인 맥락을 제공할 수 있습니다.

또 다른 상수 "NFILE"은 전체 시스템(모든 프로세스/사용자)에 대한 최대 열린 파일 수이며, 각 프로세스의 열린 파일 테이블에는 "파일" 구조에 대한 포인터가 포함되어 있습니다.minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/conf/cc. 이는 또한 시스템 전체의 열린 파일 테이블의 크기를 결정하는 컴파일 타임 상수이기도 합니다(실제로 사용되는지 여부에 관계없이 메모리를 소모하기도 함).

이는 역사적 이유가 있음을 보여준다. NOFILE 파일 설명자는 사용 여부에 관계없이 각 프로세스에서 유지됩니다. RAM이 부족하면 사용하지 않는 메모리를 유지하는 것을 피하고 싶을 것입니다. 요즘에는 RAM이 더 저렴할 뿐만 아니라 사전 주문도 더 이상 그런 방식으로 이루어지지 않습니다.

ulimit -n그것은 내 관찰을 확인시켜줍니다. 최대 값으로 높이는 대신 1024로 유지해야 하는 이유를 찾을 수 없습니다 ulimit -n $(ulimit -Hn). 파일 설명자가 실제로 사용될 때만 메모리가 점유됩니다.

내가 아는 한, 그렇습니다. 파일 최대 커널 하드 제한은 메모리 할당 정책 때문입니다(inode 구조에 대한 메모리는 사전 할당됨). 이 전략은 당시에는 일반적이고 직관적이며 효율적이었으며 DOS, Windows, Linux 및 기타 운영 체제에서 공유되었습니다.

^{요즘에는 여러분이 보는 엄청난 숫자가 이론적 최대값(2 64} -1) 이라고 생각합니다 . "실제" 파일 최대값은 런타임에 할당되며 ulimit( ulimit -Hn및 )를 통해 ulimit -Sn설정할 수 있습니다. 따라서 "file-max"는 ulimit의 최대값일 뿐이며 본질적으로 의미가 없습니다. 이는 "어떤 일이 있어도 ulimit에 RAM이 부족할 때까지"를 의미합니다.

파일 설명자를 모니터링하기 위해 네트워킹 코드에서 일반적으로 사용되는 함수는 select()많은 구현에서 최대 1023개의 파일 설명자만 처리합니다. 이 기능은 일반적으로 새 코드에서는 더 이상 사용되지 않는 것으로 간주되지만 이 기능을 사용하는 소프트웨어는 더 높은 번호의 파일 설명자를 처리할 때 제대로 작동하지 않습니다.

파일 설명자는 사용자 프로세스에 의해서만 정수 값으로 처리되며 파일 설명자 세트에 대한 작업은 가능한 파일 설명자의 작은 고정 범위를 가정하고 각 파일 설명자가 처리 대상으로 표시되었는지 확인하는 범위를 반복하여 구현됩니다. 최대 파일 설명자 수가 너무 많으면 비용이 매우 많이 들 수 있습니다.