어떤 프로세스가 CPU를 먹고 있는지 추측만 할 수 있는 문제를 겪었습니다.
내 CPU 사용량은 psensor의 모든 코어에 대해 약 80%였습니다.
나는 시도했고 , htop( 마지막으로 sudo를 사용해 시도했지만 소용이 없었습니다). 이 모든 것들은 (내가 알고 있던) 범인 pid를 약 7%만 사용하여 보여주었습니다...topps -A -o pcpu,pid,cmd --sort +pcpu
해당 pid에 대해 SIGKILL을 수행하면 모두 정상으로 돌아갑니다.
테스트하기 위해 터미널에서 무한 루프를 수행했지만 while true;do echo -n;donehtop에서 명확하게 볼 수 있었습니다. 그래서 문제를 일으키는 원인이 그것과 비슷하지 않은 것 같아요 ...
그렇다면 추측하지 않고도 범인을 찾을 수 있는 다른 방법이 있었는지 궁금합니다.
psensor다시 생각해보면, 그 값을 표시할 수 있었지만 다른 것들은 표시할 수 없었던 계산 및 "시스템 로드 표시기 애플릿"이 무엇을 사용하는지 알고 싶습니다 .
추신.:대기 시간에 대한 연결, 로드 평균에 대한 연결
답변1
정확한 힌트를 제공할 만큼 세부 사항에 대해 잘 알지 못하지만 실제 발생한 로드와 표시된 CPU 사용량 사이에는 두 가지 차이점이 있다고 생각합니다.
프로세스는 여러 스레드로 구성될 수 있으며
top이를 요약하지 않을 수도 있습니다. 다음을 통해 스레드 수를 확인할 수 있습니다.ps -eo pid,nlwp,%cpu,user,args에서는
top스레드 처리를 전환할 수 있습니다H. 각 스레드의 CPU 사용량은 일반적으로 매우 낮습니다.프로세스로 인해 많은 I/O가 발생할 수 있습니다. I/O 대기 시간은 전체 CPU 로드의 일부이지만 프로세스의 CPU 사용량 값의 일부가 아닐 수도 있습니다. 따라서
wait의 값을 확인하십시오top. 어떤 프로세스가 어느 정도까지 원인이 되는지 알려주지는 않지만 값이 낮으면 그 효과를 설명할 수 없습니다.
답변2
유닉스 시스템에서 실행되는 코드는 커널 코드와 사용자 랜드 코드로 분류됩니다. 사용자 랜드 코드는 항상 프로세스에 연결되므로 CPU가 사용자 랜드 코드를 실행하는 데 바쁜 경우 top. 커널 코드는 일반적으로 프로세스에 연결됩니다. 커널이 시스템 호출을 실행하는 경우 커널 내부 처리는 해당 프로세스에 속하는 것으로 간주됩니다. 커널 시간은 유틸리티에서 보고한 "시스템 시간"입니다 time.
커널이 수행하는 작업 중 일부는 하나의 프로세스에 대해 직접 설명할 수 없습니다. 특히 하드웨어 인터럽트는 본질적으로 특정 프로세스에 속하지 않습니다. 예를 들어, 네트워크 카드에 의해 인터럽트가 발생했다고 가정합니다. 커널은 코드를 실행하여 네트워크 패킷을 읽고 구문 분석합니다. 지금까지 어떤 프로세스도 포함되지 않았습니다. 방화벽 규칙을 통해 패킷이 거부될 수 있으며, 이 경우 어떤 프로세스도 해당 처리 시간을 요구할 수 없습니다. 프로세스가 해당 패킷을 수신하게 되면 수신 시간 중 일부가 해당 프로세스의 탭에 기록되지만 초기 단계에는 기록되지 않습니다.
따라서 어떤 프로세스에도 속하지 않는 CPU 시간을 가질 수 있습니다. 그러나 때로는 CPU 시간이 일부 프로세스에 의해 간접적으로 발생하는 경우도 있습니다. 예를 들어, 패킷을 다른 시스템으로 보내고 이 다른 시스템이 응답하도록 하는 프로세스가 있지만 방화벽이 응답 패킷을 차단하는 경우 응답 패킷을 구문 분석하고 삭제하는 데 소요된 시간은 해당 전송 프로세스로 추적되지 않습니다. 그러나 전송 프로세스가 중지되어 원격 시스템의 응답이 중지되면 커널은 더 이상 패킷을 거부하는 데 시간을 소비하지 않습니다. 물론 네트워크는 단지 하나의 예일 뿐이며, 커널이 하나의 프로세스를 직접 추적할 수 없는 작업을 수행하는 다른 많은 방법이 있습니다.
이것이 무슨 일이 일어나고 있는지 확신할 만큼 충분한 정보를 제공하지 않았지만(커널 디버거 없이는 알아내기 어려울 수 있음) 이는 그럴듯한 설명입니다.
답변3
htop,ps,top을 사용하고 싶지 않다면 systemtap을 사용하여 더 낮은 수준의 세부정보를 확인할 수 있습니다.