시스템 전체 파일 핸들 수 문제

더 짧고 집중적인 다른 질문을 시도해 보세요. 이것은 일반적인 "왜 file-nr이 예상보다 낮은 숫자를 보고합니까?"라는 질문이 아닙니다. 나는 반대의 문제가 있습니다.

Linux 2.6 시스템에서 파일 핸들이 누출되고 있습니다. 나는 정기적으로 /proc/sys/fs/file-nr을 cat하기 때문에 이것을 알고 있습니다. 첫 번째 숫자는 몇 시간에 걸쳐 상승 추세이고 두 번째 숫자는 항상 0입니다. 첫 번째 숫자가 세 번째 숫자에 도달하면 로그인이 불가능해지고 새 쉘이 생성되지 않습니다. 그래서 나는 file-nr의 출력을 신뢰하며 심각한 파일 핸들 누출이 있다고 믿을 만한 이유가 있습니다. (시스템이 항상 이 작업을 수행하는 것은 아니며 이러한 일이 발생하기 시작하는 운율이나 이유를 찾지 못했지만 상당히 일반적입니다.)

이제 이상한 부분이 나옵니다. 루트로 실행하면서 /proc/each 프로세스 ID/fd를 통해 모든 fd에 대해 ls -l을 수행했습니다. 나는 이 작업을 루트로 수행하고 있으므로 모든 프로세스에 대한 모든 파일 핸들을 볼 수 있습니다.

내 제한된 이해에 따르면 ls 출력에는 file-nr이 표시하는 것과 동일한 수의 핸들이 표시되어야 합니다. /proc/#을 실행하는 동안 프로세스가 왔다 갔다 할 수 있고 파일을 열거나 닫을 수 있기 때문에 그것이 정확할 것이라고 기대하지 않습니다. 하지만 충분한 시간이 지나면 평균적으로 대략적인 합의가 이루어질 것으로 기대합니다. 첫 번째 질문은 이것이 합리적인 가정인가 하는 것입니다. 말이 안 된다면 왜 안 될까요?

file-nr은 핸들 수가 천천히 증가하여 점차적으로 65536을 향해가는 것을 보여주기 때문에 이 질문을 합니다. 그러나 /proc/ids../fd의 총 출력은 다음과 같습니다.수천핸들 수가 적습니다. 예를 들어, 한때 file-nr은 "9900 0 65536"처럼 보였지만 proc의 프로세스당 파일 핸들 수는 2000개 미만이었고 반복 실행에도 거의 동일하게 유지되었습니다. 유출된 핸들이 무엇이든 프로세스로 표시되지는 않습니다.

차이가 7,000 이상인가요? 프로세스가 미친 듯이 시작 및 중지되지 않고 파일을 미친 듯이 열고 닫아서는 안 되는 경우는 언제입니까? 프로세스당 하드 파일 핸들 수는 1024개로 제한되므로 이 문제를 일으키는 프로세스가 하나도 아닙니다. 시스템에는 수십 개의 죽은 프로세스가 표시되지만 죽은 프로세스가 파일 핸들을 유지할 수는 없을 것 같습니다. 그리고 나는 다른 사람들이 내 작업을 확인하도록 하여 그것이 ls를 어리석게 오용하는 것처럼 보이지 않도록 노력합니다.

이것은 나에게 중요한 문제이며, 누군가 카운트에 그렇게 큰 차이가 있는 이유를 설명할 수 있다면 중요한 문제와 생산 중단 문제를 해결할 수 있는 방향으로 나아갈 수 있을 것입니다.

나는 lsof를 사용하고 있지 않다는 점에 유의하십시오. 이는 시스템에서 제거되었습니다. 그러나 나는 "열린 파일"과 동일하지 않을 수 있는 실제 파일 핸들에만 관심이 있기 때문에 /proc/#s를 걷는 것만으로도 충분합니다. 아니면 그렇게 생각했습니다.