대용량 시스템에 대한 실제 최대 열린 파일 설명자 (ulimit -n)


76

최근 애플리케이션로드 테스트를 시작한 결과 약 24 시간 후에 파일 디스크립터가 부족한 것으로 나타났습니다.

Dell 1955에서 RHEL 5를 실행하고 있습니다.

CPU : 2 x 듀얼 코어 2.66GHz 4MB 5150 / 1333FSB RAM : 8GB RAM HDD : 2 x 160GB 2.5 "SATA 하드 드라이브

파일 디스크립터 한계를 확인했으며 1024로 설정되었습니다. 응용 프로그램에 약 1000 개의 들어오는 연결과 1000 개의 나가는 연결이있을 수 있다는 점을 고려하면 상당히 낮은 것 같습니다. 열어야 할 실제 파일은 말할 것도 없습니다.

내 첫 번째 생각은 ulimit -n 매개 변수를 몇 자릿수만큼 늘리고 테스트를 다시 실행하는 것이었지만이 변수를 너무 높게 설정하면 잠재적 인 영향을 알고 싶었습니다.

소프트웨어가 이론적으로 열 수있는 파일 디스크립터 수를 알아내는 것 외에 다른 방법으로 모범 사례가 있습니까?

답변:


73

이러한 제한은 여러 명의 "일반"사용자 (앱이 아닌)가 서버를 공유하는 시점에서 시작되었으며 너무 많은 리소스를 사용하지 못하도록 보호하는 방법이 필요했습니다.

고성능 서버의 경우 매우 낮으며 일반적으로 서버를 매우 높은 수로 설정합니다. (24k 정도) 더 높은 숫자가 필요한 경우 sysctl file-max 옵션도 변경해야합니다 (일반적으로 우분투에서는 40k, rhel에서는 70k로 제한됨).

ulimit 설정 :

# ulimit -n 99999

Sysctl Max 파일 :

#sysctl -w fs.file-max=100000

또한 응용 프로그램에 메모리 / 파일 설명자 누출이 있는지 확인해야 할 수도 있습니다. lsof를 사용하여 열려 있는지 확인하십시오. 응용 프로그램 버그를 해결하기 위해 시스템을 변경하지 마십시오.


1
감사합니다. 우리는 리소스 누수에 대해 확실히 우려하고 있지만 실제로는 그렇지 않습니다. 우리는 lsof와 netstat를 모두보고 있었으며 숫자는 높지만 계속 증가하지 않고 확장 및 축소됩니다. 누출이 발생하면 열린 소켓 또는 설명자 수가 계속 증가 할 것으로 예상합니다.
Kevin

2
ulimit한계는 있지만, 프로세스 당, 사용자 당 아닙니다! unix.stackexchange.com/questions/55319/…를 참조하십시오 . 그리고 fs.file-max설정은 서버 전체에 대한 것입니다 (따라서 모든 프로세스가 함께).
Tonin

15

당신은 항상 그냥 수

cat /proc/sys/fs/file-nr

'고부하'상황에서 사용중인 파일 디스크립터 수를 확인하십시오.

최대로-그것은 당신이하는 일에 달려 있습니다.


여기 위의 명령이 나에게 보여 졌을 때 143000이 충분하다고 생각했습니다 8288 0 793377!
Sridhar Sarnobat

6

파일 디스크립터가 tcp 소켓 등인 경우 소켓 버퍼 및 기타 커널 오브젝트에 많은 양의 메모리를 사용할 위험이 있습니다. 이 메모리는 교체 할 수 없습니다.

그러나 그렇지 않다면 원칙적으로 아무런 문제가 없을 것입니다. 사용할 커널 메모리 양을 확인하거나 테스트하려면 커널 설명서를 참조하십시오.

우리는 큰 문제없이 ~ 10k 파일 디스크립터가 열려있는 (대부분 실제 디스크 파일에서) 데이터베이스 서버를 실행하지만 64 비트이며 많은 램을 가지고 있습니다.

ulimit 설정은 프로세스마다이지만 시스템 전체에도 제한이 있습니다 (기본적으로 32k라고 생각합니다)


2

모범 사례를 개인적으로 알고 있지 않습니다. 시스템 기능에 따라 다소 주관적입니다.

현재보고있는 1024는 시스템 전체가 아니라 사용자 당 한도입니다. 이 시스템에서 몇 개의 응용 프로그램을 실행하는지 고려하십시오. 이게 유일한가요? 이 응용 프로그램을 실행하는 사용자가 다른 작업을 수행하고 있습니까? (IE 사용자가이 계정을 사용하여 잠재적으로 도망 갈 수있는 스크립트를 로그인하고 실행합니까?)

상자 가이 하나의 응용 프로그램을 실행 중이고 해당 응용 프로그램을 실행하는 계정이 해당 목적으로 만 제공된 경우, 제안한대로 한도를 높이는 데 아무런 해가 없습니다. 사내 개발자 팀이라면 의견을 묻습니다. 타사 공급 업체의 제품인 경우 특정 요구 사항이나 권장 사항이있을 수 있습니다.


@Grahamux 시스템은이 응용 프로그램 전용이며 응용 프로그램을 실행하는 사용자는이 응용 프로그램 만 실행합니다. 저는 사내 개발 팀의 일원이므로 도움이 없습니다.
Kevin

제한은 사용자 당이 아니라 프로세스 당입니다. 참조 unix.stackexchange.com/questions/55319/...
Tonin

1

이것은 "개발 환경에서 테스트"로 가장 잘 대답 한 질문 중 하나 인 것 같습니다. 몇 년 전, 당신이 이것을 엉망으로 만들었을 때 태양은 긴장했지만 그 긴장은 아닙니다. 당시의 한계는 1024였습니다. 그래서 나는 그것이 리눅스에서 지금 동일하다는 것을 알게되어 약간 놀랐습니다.

귀하의 질문에 대한 답변을 Google에 검색했을 때 다음 링크가 교육되었음을 발견했습니다. http://www.netadmintools.com/art295.html

그리고 이것은 또한 https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.