갑자기 문제가 발생했습니다. 모든 애플리케이션과 서버가 정상적으로 실행되고 있었는데 갑자기 열린 파일 수가 급증했습니다.
다음 명령으로 확인하고 있습니다.
cat /proc/sys/fs/file-nr
확인해 보니 44544 0 128000
열린 파일 수가 44544로 표시되었습니다.
하지만 이 명령을 확인하면 lsof | wc -l
- 28384가 표시됩니다.
그럼 어느 것이 맞나요?
최대 열린 파일 제한은 65535입니다.
ulimit -a
open files (-n) 65535
열린 파일을 더 많이 사용하는 상위 5개 프로세스를 알고 싶습니다. 여기에서 이를 얻을 수 있지만 lsof
여기에 표시된 개수는 위에서 언급한 다른 명령과 매우 다릅니다.
이 명령으로 계산된 프로세스의 세부 정보를 얻을 수 있습니까 cat /proc/sys/fs/file-nr
?
아래 링크에 따르면 불가능하다고 나오네요. lsof 명령을 사용하지 않고 열린 파일 설명자를 표시하는 방법
해결책이 있나요? 더 많은 열린 파일을 사용하여 갑자기 시작된 프로세스를 찾아야 합니다.
고쳐 쓰다 모두에게 폐를 끼쳐드려 죄송합니다. 내가 저지른 실수는 루트 디렉토리에서 lsof|wc -l을 확인하지 않았다는 것입니다. 그렇기 때문에 저는 큰 차이를 봅니다.
file -nr과 lsof | wc -l(루트 디렉토리에서)의 출력에는 여전히 차이가 있습니다. lsof 개수가 파일 -nr 개수보다 큽니다. 그 이유는 file -nr이 일부 디렉토리(lsof가 파일로 취급함)를 무시하기 때문입니다. 이는 Google 자체에 대한 조사를 통해 알아낸 것입니다. 그래도! 모두의 도움에 감사드립니다!
답변1
여기에는 두 가지 문제가 있는 것 같습니다. 먼저, file-nr 및 file-max 구조에 대한 전체 문서는 다음에서 찾을 수 있습니다.
https://www.kernel.org/doc/Documentation/sysctl/fs.txt
이는 해당 파일의 필드를 다음과 같이 정의합니다.
file-nr의 세 가지 값은 할당된 파일 핸들 수, 할당되었지만 사용되지 않은 파일 핸들 수, 최대 파일 핸들 수를 나타냅니다. Linux 2.6은 사용 가능한 파일 핸들 수를 항상 0으로 보고합니다. 이는 버그가 아니며 단지 할당된 파일 핸들 수가 사용된 파일 핸들 수와 정확히 일치한다는 의미일 뿐입니다.
이것이 충분히 명확하기를 바랍니다. 두 번째 질문은 위에서 언급한 스레드에서 이미 답변되었습니다(https://serverfault.com/questions/485262/number-of-file-descriptors- Different- Between-proc-sys-fs-file-nr-and-proc-pi)로 전송되는 것 같습니다.
- 프로세스에서 사용하는 파일 설명자의 좋은 근사치를 얻으려면 "lsof를 사용"하고 출력을 적절하게 필터링하세요.
- 시간에 맞춰 파일 설명자 사용에 대한 스냅샷을 얻기 위해 /proc 파일 시스템을 순회합니다(그리고 출력은 계속 필터링되어야 합니다).
특정 지점에서 사용되는 FD의 양은 시스템에서 매우 빠르게 변동될 수 있으므로 정확한 측정항목을 얻는 것이 어렵습니다.
다음 스레드는 "lsof" 메소드에 대한 필터링 방식을 제안합니다.