CPU 사용량 지표 분석!

맞습니다. 여기서 제가 말하는 것은 모든 성능 모니터링 제품에서 모든 사람이 어디에서나 사용하는 "%CPU" 측정항목입니다. 이를 보려면 top(1) 명령을 사용하십시오.
90% CPU 사용량은 다음을 의미한다고 생각할 수 있습니다.

실제로 다음을 의미할 수도 있습니다:

정지란 프로세서가 명령 처리에서 아무런 진전도 이루지 못하고 있음을 의미합니다. 일반적으로 프로세서가 메모리 입력/출력을 기다리고 있기 때문입니다. 위에서 그린 비율(바쁨과 막힘 사이)은 실제 제작 환경에서 자주 볼 수 있는 것입니다. 당신은 기본적으로 정지 상태에 있고 심지어 그것을 알지 못할 수도 있습니다.

이것은 당신에게 무엇을 의미합니까? 정지된 CPU의 양을 알면 코드 감소 또는 메모리 I/O 감소 간의 성능 조정 노력을 안내할 수 있습니다. 특히 CPU를 기반으로 리소스를 자동으로 확장하는 클라우드에서 CPU 성능에 대해 우려하는 사람은 %CPU가 정지되는 위치를 파악하면 도움이 될 것입니다.

CPU 사용량은 실제로 얼마나 되나요?

우리가 CPU 사용량이라고 부르는 측정값은 실제로 "유휴 시간이 아닌 시간"입니다. 즉, CPU가 유휴 스레드를 실행하지 않는 시간입니다. 운영 체제 커널(무엇이든)은 일반적으로 컨텍스트 전환 중에 이 측정항목을 추적합니다. 유휴 상태가 아닌 프로세스가 실행을 시작한 후 100밀리초 동안 중지하는 경우 커널은 여전히 ​​전체 기간 동안 CPU를 사용 중인 것으로 간주합니다.

이 측정항목은 시간 공유 시스템만큼 오래되었습니다. 선구적인 시간 공유 시스템인 Apollo Lunar Module 유도 컴퓨터는 유휴 스레드를 "DUMMY JOB"이라고 불렀습니다. 엔지니어들은 컴퓨터 작업의 척도로서 유휴 스레드를 실행하는 데 걸리는 주기와 실제 작업을 실행하는 데 걸리는 주기를 추적했습니다. 사용량을 나타내는 중요한 지표입니다.

그럼 이 지표에는 어떤 문제가 있나요?

요즘 CPU는 메인 메모리보다 훨씬 빨라졌고, 대기 메모리는 여전히 소위 "CPU 사용량"의 큰 부분을 차지합니다. %CPU 수치가 높다면 프로세서가 병목 현상을 일으킨다고 생각할 수 있습니다(예: 방열판과 팬 아래의 CPU 패키지). 실제로는 해당 DRAM 모듈이 병목 현상을 일으킵니다.

이와 관련된 상황은 점점 더 심각해지고 있습니다. 오랫동안 프로세서 제조업체는 DRAM보다 클럭 속도를 높여 액세스 지연 시간을 늘렸습니다. 이것이 소위 "CPU DRAM 갭"입니다. 이러한 상황은 3GHz 프로세서가 출시된 2005년경에 안정화되었습니다. 그 이후로 프로세서는 성능을 향상시키기 위해 더 많은 코어와 하이퍼스레딩을 사용하고 멀티 소켓 구성을 사용하여 메모리 하위 시스템 요구 사항을 더욱 높였습니다. 프로세서 제조업체는 더 크고 스마트한 CPU 캐시와 더 빠른 메모리 버스 및 상호 연결 기술을 사용하여 이러한 메모리 병목 현상을 완화하려고 노력하고 있습니다. 그러나 우리는 여전히 일반적으로 정체 상태에 있습니다.

CPU가 실제로 무엇을 처리하고 있는지 어떻게 알 수 있나요?

PMC(성능 모니터링 카운터)를 사용할 수도 있습니다. 이는 Linux perf 및 기타 도구를 사용하여 읽을 수 있는 하드웨어 카운터입니다. 예를 들어 전체 시스템을 10초 동안 측정하는 경우:

으아악

여기서 핵심 측정항목은 사이클당 명령(예: IPC)으로, CPU 클록 사이클당 평균적으로 완료하는 명령 수를 보여줍니다. 간단히 말해서, 값이 높을수록 좋습니다. 위 예에서 0.78은 좋게 들리지만(시간의 78% 사용) 프로세서의 최고 속도가 4.0이라는 것을 알면 그렇지 않습니다. 이는 명령어 페치/디코드 경로를 나타내는 4-와이드라고도 합니다. 이는 CPU가 클록 주기당 4개의 명령을 폐기(완료)할 수 있음을 의미합니다. 따라서 4와이드 시스템에서 IPC가 0.78이라는 것은 CPU가 최대 속도의 19.5%로 실행되고 있음을 의미합니다. 새로운 Intel Skylake 프로세서는 5와이드입니다.

더 자세히 알아보는 데 사용할 수 있는 PMC가 수백 개 더 있습니다. 정체 기간을 다양한 유형별로 직접 측정할 수 있습니다.

클라우드 속

如果你在虚拟环境中，可能无法访问PMC，这要看虚拟机管理程序是否为访客（guest）支持PMC。我最近写过一篇文章：《EC2的PMC：测量IPC》，表明了如今PMC如何可用于基于Xen的AWS EC2云上面的专用主机类型。

实际对策

如果你的IPC

如果你的IPC > 1.0，你可能是指令密集型。想方设法减少代码执行：消除不必要的工作和缓存操作等。CPU火焰图是一款很适合开展这项调查的工具。至于硬件调优，不妨试一试更快的时钟频率和数量更多的核心/超线程。

性能监测产品应该能告诉你什么？

每一款性能工具应该显示IPC以及%CPU。或者将%CPU分解成指令完成周期与停滞周期，比如%INS和%STL。

面向Linux的tiptop(1)可按进程显示IPC：

tiptop –                 [root]
Tasks: 96 total,    3 displayed                                 screen   0: default
 
PID [ %CPU] %SYS  P   Mcycle   Minstr  IPC %MISS %BMIS  %BUS COMMAND
3897   35.3   28.5    4   274.06   178.23 0.65   0.06  0.00   0.0     java
1319+   5.5    2.6   6    87.32   125.55 1.44   0.34  0.26  0.0    nm-applet
900    0.9  0.0    6    25.91    55.55 2.14   0.12  0.21     0.0     dbus-daemo

CPU使用率具有误导性的其他理由

让CPU使用率具有误导性的不仅仅是内存停滞周期。其他因素包括如下：

• 温度过高导致处理器停滞。
• 睿频加速（Turboboost）导致时钟频率不一。
• 内核因speedstep导致时钟频率不一。
• 平均值方面的问题：1分钟内的使用率为80%，隐藏了100%的突发使用率。
• 自旋锁：CPU被使用，有很高的IPC，但是应用程序在处理指令方面没有合理的进展。

结束语

CPU使用率已成为一个极具误导性的度量指标：它包括了等待主内存的周期，而这类周期在现代工作负载中占了大头。如果使用额外的度量指标，你就能搞清楚%CPU到底意味着什么，包括每个周期指令（IPC）。IPC 1.0可能意味着指令密集型。我在之前的一篇文章中介绍了IPC，包括介绍了衡量IPC所需要的性能监控计数器（PMC）。 显示%CPU的性能监控产品还应该显示PMC度量指标，解释那个值意味着什么，那样才不会误导最终用户。比如说，它们可以一并显示%CPU及IPC，以及/或指令完成周期与停滞周期。有了这些度量指标，开发人员和操作人员才能决定如何才能更好地调优应用程序和系统。

위 내용은 CPU 사용량 지표 분석!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!