저는 오래된 레거시 애플리케이션을 작업 중인데 아무도 설명하지 않는 일부 설정에 계속 직면하고 있습니다.
분명히 어느 시점에서 애플리케이션의 일부 프로세스가 프로세스당 허용되는 최대 파일 설명자 수에 도달했으며 팀은 셸의 초기화 파일(.kshrc)에 다음을 추가하여 제한을 늘리기로 결정했습니다.
((nfd=16#$(/etc/sysdef | grep "file descriptor" | awk '{ print $1 }' | cut -f3 -d "x")))
ulimit -n $nfd
이렇게 하면 ulimit -n출력이 256에서 65536으로 증가합니다. 우리 머신의 거의 모든 프로세스는 이 높은 소프트 제한 하에서 실행됩니다.
이 조잡한 접근 방식에는 위험이 있습니까? 올바른 교정 방법은 무엇입니까 ulimit?
부가 질문: 현재 실행 중인 프로세스에서 사용되는 FD 수를 어떻게 알 수 있나요?
환경
- 운영 체제: SunOS....5.10 Generic_120011-14 sun4u sparc SUNW, Sun-Fire-V215
- 하우징: KsH 버전 M-11/16/88나
답변1
실행 중인 프로세스에서 사용 중인 파일 설명자 수를 보려면 다음을 실행하세요.pfiles프로세스 ID에.
프로세스에 사용 가능한 fd 수를 늘리면 소프트웨어 및 작성 방법에 따라 성능에 영향을 미칠 수 있습니다. 프로그램이 데이터 구조의 크기를 조정하는 데 사용할 수 있는 fd의 최대 수입니다.select(3c)비트마스크 배열을 사용하거나 모든 fd에 대해 루프 닫기와 같은 작업을 수행합니다(Solaris용으로 작성된 소프트웨어는 다음을 사용할 수 있음).fdwalk(3c)이 함수는 가능한 가장 큰 값이 아닌 열린 fd에 대해서만 이 작업을 수행합니다.
답변2
우리가 해결해야 할 문제를 확인하세요한계애플리케이션의 셸에는 256개의 사용 가능한 파일 설명자만 있습니다. 응용 프로그램은 매우 오래되었으며 최대 fd 수를 사용하고 해당 숫자를 "unsigned char" 유형의 변수에 넣으려고 시도합니다. 이 변수는 최대 256의 정수만 보유할 수 있습니다(코어 덤프 발생). 따라서 이 특정 애플리케이션의 경우 사용 가능한 fd를 256개로 제한해야 합니다.
alanc와 달리 제안한 대로 매우 높게 설정하는 것이 성능에 측정 가능한 영향을 미칠 것이라고는 실제로 믿지 않습니다. 이렇게 하지 않는 이유는 악성 프로세스가 너무 많은 리소스를 소비하는 것을 방지하기 위한 것입니다.
마지막으로 alanc가 맞습니다. 이 pfiles명령은 특정 프로세스에서 현재 사용 중인 fd 수를 알려줍니다. 하지만 이 pfiles명령은 검사 프로세스를 일시적으로 중지한다는 점을 기억하세요. 명령 실행으로 인해 프로세스가 충돌하는 것을 본 적이 있지만 pfiles이는 아마도 응용 프로그램에서 결코 발생하지 않을 극단적인 경우일 것입니다. 죄송합니다. 현재 프로세스에서 사용하는 fd 수를 찾는 안전한 방법을 모르겠습니다. 내 조언: pfiles프로세스에 대해 명령을 실행한 후에는 항상 프로세스가 여전히 존재하는지 모니터링하세요.