☰

영구적으로 차단된 I/O의 원인 찾기(중단되지 않은 절전 상태의 프로세스)

tag-icon • tag-icon linux process io debugging
영구적으로 차단된 I/O의 원인 찾기(중단되지 않은 절전 상태의 프로세스)

Linux에서는 중단 불가능한 절전 모드(상태 D)에서 프로세스가 차단되었습니다. 이 원인을 어떻게 조사할 수 있나요?

나는 특별한 디버깅 기능 없이 "일반" 커널(Debian 버전)을 실행하고 있습니다.

관련 로그 항목이 없습니다. 실제로 프로세스가 시작된 시간과 내가 이를 발견한 시간 사이에는 아무것도 기록되지 않았습니다.

strace중단 없는 절전 상태이기 때문에 프로세스에 연결할 수도 없습니다. 시스템 호출의 이름을 알고 있다고 해도 반드시 도움이 되는 것은 아닙니다. 커널 내부에서 무슨 일이 일어나고 있는지 알아야 합니다.

특히, sync명령은 중단할 수 없는 절전 모드로 전환됩니다. 따라서 어딘가에서 I/O 문제가 있는 것이 틀림없지만 모든 파일 시스템이 제대로 작동하는 것 같습니다. I/O 오류에 대한 오래된 로그 항목이 있을 가능성이 높지만 찾을 수 없습니다(머신이 오랫동안 재부팅되지 않았으며 로그 항목이 많습니다). 적어도 어느 하위 시스템이 차단되고 있는지 알 수 있습니까 sync(예: 특정 PID/TID에 해당하는 커널 스레드 가져오기)? 커널 추적?

(재부팅하면 이 문제가 해결되거나 오류가 드러날 것이라고 확신하지만 무작정 버튼을 누르는 방법이 아니라 이를 조사하는 방법을 묻습니다.)

답변1

조금 늦었지만 다른 분들께는 도움이 될 것 같습니다.

내가 뭘 한거지:

  1. cat /proc/PID/stack방향을 잡기 위해. 내 경우에는 다음과 같이 작동합니다.인덱스 노드및 파일 시스템:
[<ffffffff83bbd6f1>] wait_on_page_bit+0x81/0xa0            
[<ffffffff83bced9b>] truncate_inode_pages_range+0x42b/0x750
[<ffffffff83bcf12f>] truncate_inode_pages_final+0x4f/0x60  
[<ffffffff83c6b78c>] evict+0x16c/0x180                     
[<ffffffff83c6bafc>] iput+0xfc/0x190                       
[<ffffffff83c66498>] __dentry_kill+0x158/0x1d0             
[<ffffffff83c66b35>] dput+0xb5/0x1a0                       
[<ffffffff83c4f53d>] __fput+0x18d/0x230                    
[<ffffffff83c4f6ce>] ____fput+0xe/0x10                     
[<ffffffff83ac31cb>] task_work_run+0xbb/0xe0               
[<ffffffff83a2cc65>] do_notify_resume+0xa5/0xc0            
[<ffffffff8419322f>] int_signal+0x12/0x17                  
[<ffffffffffffffff>] 0xffffffffffffffff
  1. cat /proc/PID/syscall현재 시스템 호출을 가져옵니다.
3 0x6 0x1ae4bc6d 0x1 0x559320c 0x801df5 0x60161c4e 0x7ffccee38ae0 0x7fcf1a1547bd

대표자 3명폐쇄시스템 호출, 6은 파일 설명자(시스템 호출의 첫 번째 매개변수)입니다. 전화를 걸려고 하는 중입니다 close(6).

  1. lsof -p PID, 그러나 나에 대한 설명이 없습니다.
  2. 운이 좋고 애플리케이션이 시작될 때 파일이 어딘가에 열려 있으면 해당 파일의 다른 인스턴스를 시작하고 파일을 확인할 수 있습니다 lsof. 이것이 내 상황입니다.

행운을 빌어요

관련 정보