현재 리소스 누출이 있는 시스템을 디버깅하고 있습니다. 파이프가 너무 많이 열려 있는 것 같습니다. 파이프라인을 나열하면 /proc/PROC_ID/fd
다음과 같은 파이프라인 목록이 표시됩니다.
l-wx------ 1 root root 64 Jun 30 12:32 100 -> pipe:[39199]
lr-x------ 1 root root 64 Jun 30 12:32 99 -> pipe:[39199]
이는 파이프가 열려 있고 양쪽 끝에 RW가 있음을 나타냅니다.
사용하면 lsof
이 파이프라인 ID로 많은 결과가 나오는 것을 확인했습니다.
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
myapp 7209 root 99r FIFO 0,8 0t0 39199 pipe
myapp 7209 root 100w FIFO 0,8 0t0 39199 pipe
myapp 7209 7210 root 99r FIFO 0,8 0t0 39199 pipe
myapp 7209 7210 root 100w FIFO 0,8 0t0 39199 pipe
myapp 7209 7211 root 99r FIFO 0,8 0t0 39199 pipe
myapp 7209 7211 root 100w FIFO 0,8 0t0 39199 pipe
myapp 7209 7212 root 99r FIFO 0,8 0t0 39199 pipe
...
그래서 파이프를 사용하는 스레드가 여러 개 있습니다. 이제 이 정보를 해석하는 데 도움이 필요합니다.
- 파이프 옆(가운데
ls
)의 ID는 무엇입니까? 전화로 받을 수 있는 방법이 있나요pipe()
? - 입력이
lsof
이고FIFO
아닌 이유는 무엇입니까PIPE
? 나는 확인했다맨페이지그리고 별도의 유형이 있습니다. 내가 잘못 들은 걸까? RHEL 7.2를 사용하고 있습니다.
고쳐 쓰다두 번째 문제를 더 명확하게 설명하기 위해 pipe:[<number>]
의 출력 에서 ls
개체는 익명 파이프처럼 보입니다. 그러나 lsof
유형은 그렇지 FIFO
않습니다 PIPE
. 이것이 어떻게 동일한 객체를 참조하는지 이해가 되지 않습니다.
건배
답변1
질문 1의 경우:
~에 따르면셸 명령을 사용하여 IPC 디버깅(섹션 8.7.1 참조) 39199
in은 pipe:[39199]
inode 번호입니다. 물리적 장치에 저장된 "일반" 파일과 달리 이러한 inode 번호는 가상 파일 시스템에 속하므로 실제 파일과 아무 관련이 없습니다(섹션 8.8 참조).
내가 이해하는 한, 이러한 inode의 요점은 "inode xxxx가 무엇을 참조하는지"가 아니라 inode를 공유하는 프로세스가 실제로 서로 통신하고 있다는 것입니다. 이러한 프로세스는 다음을 통해 출력될 수 있습니다.
lsof | grep <inodeNumber>