CPU를 점유하는 프로세스(top, htop, ps?)가 있는지 확인하세요.

정확한 힌트를 제공할 만큼 세부 사항에 익숙하지는 않지만 실제 유도된 로드와 표시된 CPU 사용량 사이에 두 가지 불일치 원인이 있다고 추측합니다.

1. 프로세스는 여러 스레드로 구성될 수 있으며 top이를 요약하는 것이 불가능할 수도 있습니다. 다음을 사용하여 스레드 수를 확인할 수 있습니다.

   ps -eo pid,nlwp,%cpu,user,args
   

   top스위치 스레드 처리를 사용할 수 있습니다 H. 스레드당 CPU 사용량은 일반적으로 매우 낮습니다.

2. 이 프로세스로 인해 과도한 I/O가 발생할 수 있습니다. I/O 대기 시간은 전체 CPU 로드의 일부이지만 프로세스의 CPU 사용량의 일부가 아닐 수도 있습니다. 따라서 수표 wait의 값입니다 top. 어떤 프로세스가 어느 정도 원인이 되는지 알려주지는 않지만, 값이 낮으면 그 효과를 설명할 수 없습니다.

UNIX 시스템에서 실행되는 코드는 커널 코드와 사용자 모드 코드로 구분됩니다. 사용자 모드 코드는 항상 프로세스에 연결되어 있으므로 CPU가 사용자 모드 코드를 실행 중이면 표시됩니다 top. 커널 코드는 일반적으로 프로세스에 연결됩니다. 커널이 시스템 호출을 실행하는 경우 커널 내 처리가 수행됩니다. 해당 프로세스에 속하는 것으로 간주됩니다. 커널 시간은 유틸리티에서 보고한 "시스템 시간"입니다 time.

커널이 수행하는 일부 작업은 프로세스에 대해 직접 계산할 수 없습니다. 특히, 하드웨어 인터럽트는 본질적으로 프로세스별로 다르지 않습니다. 예를 들어, 인터럽트가 네트워크 카드에 의해 트리거된다고 가정합니다. 커널은 네트워크 패킷을 읽고 구문 분석하는 코드를 실행하며 지금까지는 프로세스가 포함되지 않았습니다. 방화벽 규칙을 통해 패킷이 거부될 수 있으며, 이 경우 어떤 프로세스도 해당 처리 시간을 요구할 수 없습니다. 프로세스가 결국 패킷을 수신하면 수신 시간의 일부가 프로세스 탭에 표시되지만 초기 단계는 표시되지 않습니다.

따라서 어떤 프로세스에도 속하지 않는 CPU 시간을 가질 수 있습니다. 그러나 CPU 시간이 일부 프로세스에 의해 간접적으로 발생하는 경우도 있습니다. 예를 들어, 다른 시스템에 패킷을 보내고 다른 시스템이 응답하도록 하는 프로세스가 있지만 방화벽이 응답 패킷을 차단하는 경우 응답 패킷을 구문 분석하고 삭제하는 데 소요된 시간은 해당 전송 프로세스까지 추적되지 않습니다. 그러나 전송 프로세스가 중단되어 원격 컴퓨터의 응답이 중단되면 커널은 더 이상 패킷을 거부하는 데 시간을 소비하지 않습니다. 물론 네트워킹은 하나의 예일 뿐이며 커널이 프로세스를 직접 추적할 수 없는 작업을 수행할 수 있는 다른 방법도 많이 있습니다.

무슨 일이 일어나고 있는지 확인할 만큼 충분한 정보를 제공하지 않았지만(커널 디버거가 없으면 파악하기 어려울 수 있음) 합리적인 설명입니다.

htop, ps 및 top을 사용하지 않으려면 systemtap을 사용하여 더 많은 기본 세부정보를 얻을 수 있습니다.