☰

D("논스톱 절전") 상태로 진입하는 프로세스 빈도의 급격한 증가를 진단하는 방법

tag-icon • tag-icon performance debugging troubleshooting sleep
D("논스톱 절전") 상태로 진입하는 프로세스 빈도의 급격한 증가를 진단하는 방법

제가 작업 중인 Linux 클러스터는 최근 몇 분씩 정지되기 시작했습니다. 이 동작의 이유는 프로세스가 매우 자주 D("논스톱 절전") 상태에 들어가고 오랜 기간 동안 해당 상태를 유지하기 때문이라고 판단했습니다.

불행하게도 이 동작은 마음대로 재현하기가 어렵습니다. 일반적으로 명령이 완료되기 전에 몇 분 동안 D 상태를 유지하고 동일한 명령을 즉시 반복하면 명령의 두 번째 시간이 즉시 완료됩니다.

단일 실행 파일로 인해 이 동작이 발생하지 않습니다. 거의 모든 Unix 명령이 취약한 것 같습니다. ls, grep, wc, find, git, vim, 이름을 지정하면 됩니다.

또한 동일한 동작이 클러스터의 모든 노드에 영향을 미칩니다.

이 패턴을 보면 모든 노드가 공유하는 스토리지 시스템에 문제가 있는 게 틀림없다고 생각했습니다. 안타깝게도 저는 이 예감을 어떻게 극복해야 할지 모르겠습니다.

다행스럽게도(아마도) 명령이 D 상태로 전환되면 5~10분 동안 그대로 유지됩니다. 나는 이것이 상황을 조사하고 무슨 일이 일어나고 있는지에 대한 자세한 내용을 얻을 수 있는 충분한 시간을 제공할 것이라고 생각합니다.

내 질문은: 상태 D에 있는 프로세스의 PID가 주어지면 무슨 일이 일어나고 있는지에 대한 추가 정보를 수집하기 위해 어떤 명령을 실행할 수 있습니까?

중요한:현재 내가 주로 관심을 갖고 있는 것은진단. 특히 클러스터를 다시 시작하여 문제를 해결하는 데는 관심이 없습니다. 동일한 상황이 다시 발생하지 않도록 방지하는 방법을 알려주지 않기 때문입니다.

PS 이 문제를 해결하는 Unix 및 Linux SE보다 더 나은 SE 사이트가 있다면 기꺼이 이를 마이그레이션해 드리겠습니다.

답변1

클러스터에서 실행 중이라고 말씀하셨습니다. 여러 네트워크 컴퓨터에 걸쳐 있는 파일 시스템을 사용하고 있습니까? 프로세스 작동이 중지되면 일반적으로 이것이 원인입니다.잠시 동안(즉, 커널 코드를 실행 중이므로 I/O가 완료되어야 합니다).

최선의 선택은 대기 프로세스의 스택 추적을 얻는 것입니다. 이는 다음과 같이 수행됩니다.

$ sudo su -
# echo w > /proc/sysrq-trigger
# dmesg -T | less -S

less물론 이 명령은 선택 사항입니다.

그런 다음 해당 스택 추적을 살펴보십시오. nfs3_proc_getattrNFS를 사용하는 경우 네트워크 기반 파일 시스템에 대한 호출이 포함될 수 있습니다 .

또 다른 해결책은 을 실행하는 것입니다 gdb -p <pid>. 그러나 프로세스를 소유하지 않거나 디버그 모드가 꺼져 있는 경우 해당 명령줄 옵션에 권한 문제가 있을 수 있습니다. 이 방법으로 gdb를 시작할 수 있다면 where명령 프롬프트가 나타난 후에 시도해 보세요. 이것은 또한 스택 추적을 제공합니다. D프로세스가 진행되는 동안 이런 결과를 얻으 려고 시도한 적이 없기 때문에 실제로 작동하지 않을 수도 있습니다.

어느 컴퓨터에서나 이러한 파일을 편집할 수 있어야 한다면 좋은 해결책이 없습니다. 그렇지 않으면 HFS와 같은 것이 더 적합할 수도 있습니다. 이는 파일을 로컬로 복사한다는 점을 제외하면 네트워크 기반 파일 시스템과 유사합니다. 따라서 파일에 액세스할 때 해당 파일은 현재 사용 중인 동일한 컴퓨터에 있으며 명령은 항상 빠르게 유지됩니다.

마지막 생각들:NFS로 인해 프로세스가 100% 중단되는 상황이 있었습니다. 나는 그들에 대해 아무것도 할 수 없습니다 kill -9. 이를 제거하는 유일한 방법은 재부팅하는 것입니다. 이는 프로세스가 현재 커널 공간에 있고 커널이 이러한 프로세스를 안전하게 삭제할 수 없기 때문입니다. 사용자 모드로 돌아가려면 전송된 신호를 수신할 수 있을 때까지 기다려야 합니다 kill. 그래서 오랫동안 파일 시스템을 사용하지 않았습니다. 그것은 가치가 없어. NFS를 올바르게 마운트 해제하기 전에 VM을 종료하면 문제가 발생합니다. (VM을 다시 시작하면 이전 NFS 마운트 지점이 복원되지 않습니다.)

관련 정보