장기 실행 응용 프로그램이 때때로 최대 열린 파일 설명자 제한( )을 초과하는 이유를 찾으려고 합니다 ulimit -n. 스파이크가 발생하는 시기를 확인할 수 있도록 애플리케이션에서 열려 있는 파일 설명자 수를 주기적으로 기록하고 싶습니다.
lsof여기 에는 제외된 항목이 많이 포함되어 있다는 것을 알고 있습니다 /proc/$PID/fd. 이는 열린 파일 설명자 제한과 관련이 있습니까? 즉, lsof에서 또는 에서 정보를 기록해야 합니까 /proc/$PID/fd?
답변1
tl;dr은 ls -U /proc/PID/fd | wc -l이보다 작아야 하는 숫자를 알려줍니다 ulimit -n.
/proc/PID/fdepoll또는 inotify핸들, O_PATH또는 로 열린 "불투명" 디렉토리 핸들, signalfd()또는 에 의해 memfd_create()반환된 소켓 accept()등과 같은 이상한 파일 설명자를 포함하되 이에 국한되지 않고 프로세스에서 열린 모든 파일 설명자를 포함해야 합니다.
나는 아주 좋은 lsof사용자 는 아니지만 lsof그것으로부터 정보를 얻습니다 /proc. procfs프로세스에 연결하거나 프로세스에 연결하는 것 외에 Linux의 프로세스에서 파일 설명자 목록을 열 수 있는 다른 방법은 없다고 생각 합니다 ptrace.
ulimit -n그럼에도 불구하고 프로세스의 현재 및 루트 디렉터리, 매핑된 파일(자체 바이너리 및 동적 라이브러리 포함) 및 제어 터미널은 ( )로 설정된 제한에 포함되지 않으며 프로세스에서 명시적으로 보유하지 않는 한 열린 파일 RLIMIT_NOFILE에 표시되지 않습니다 . /proc/PID/fd그들의 손잡이.