首頁  >  文章  >  系統教程  >  CPU使用率度量指標的分析!

CPU使用率度量指標的分析!

WBOY
WBOY原創
2024-06-01 21:18:08485瀏覽

沒錯,我在這裡所說的是每個人在到處使用的「%CPU」這個度量指標,用於每一款效能監控產品。用top(1)指令來查看。
你可能認為90%的CPU使用率意味著:
CPU使用率度量指標的分析!
而實際上它可能意味著:
CPU使用率度量指標的分析!
停滯(stalled)意味著處理器在處理指令方面沒有進展,通常是由於處理器在等待記憶體輸入/輸出。我在上面劃分的比例(忙碌和停滯之間)是我在實際的生產環境中經常看到的情況。你很可能基本上處於停滯狀態,但渾然不知罷了。

這對你來說代表什麼呢?了解你的多少CPU處於停滯狀態可以指導減少程式碼或減少記憶體輸入/輸出之間的效能調優工作。誰要關注CPU效能,尤其是根據CPU自動擴展資源的雲,如果知道%CPU中停滯的部分,那將大有益處。

CPU使用率其實是什麼東東?

我們稱為CPU使用率的衡量指標其實是「非閒置時間」(non-idle time):也就是CPU未執行閒置執行緒的時間。你的作業系統核心(無論它是什麼核心)通常在上下文切換過程中追蹤這個指標。如果非閒置進程開始運行,然後停止100毫秒,核心還是認為該CPU在那整段時間都被使用。

這個度量指標的歷史與分時系統一樣久遠。 Apollo Lunar Module導引計算機(一種開創性的分時系統)稱其閒置線程為“DUMMY JOB”,工程師們跟踪了運行該閒置線程的周期和運行實際任務的周期,將這視為一個衡量計算機使用率的重要指標。

那麼這個指標哪裡不對勁呢?

現在,CPU的速度已變得比主記憶體快得多,等待內存在仍然所謂的「CPU使用率」中佔了大頭。如果你看到數值很高的%CPU,可能認為處理器是瓶頸(即散熱片和風扇下面的CPU封裝件),而實際上那些DRAM模組才是瓶頸。

這方面的情形一直變得越來越嚴峻。長久以來,處理器廠商提高時脈速度的振幅超過DRAM提高存取延遲的幅度,這就是所謂的「CPU DRAM缺口」( CPU DRAM gap)。這種情形在3 GHz處理器面世的2005年前後趨穩;自那以後,處理器使用更多的核心和超線程來提升性能,另外使用多插座配置,這一切給內存子系統提出了更高的要求。處理器廠商試圖採用更龐大、更智慧的CPU快取以及更快速的記憶體匯流排和互連技術來緩解這個記憶體瓶頸。但是我們仍然通常處於停滯狀態。

如何顯示CPU到底在處理什麼?

不妨使用效能監控計數器(PMC):這是使用Linux perf及其他工具可以讀取的硬體計數器。比如說,將整個系統測量10秒鐘:

# perf stat -a — sleep 10
Performance counter stats for ‘system wide’:
641398.723351      task-clock (msec)         #  64.116 CPUs utilized         (100.00%)
379,651      context-switches          #    0.592 K/sec                 (100.00%)
51,546      cpu-migrations           #    0.080 K/sec                 (100.00%)
13,423,039       page-faults              #    0.021 M/sec
1,433,972,173,374      cycles                  #    2.236 GHz                  (75.02%)
<not>      stalled-cycles-frontend
<not>      stalled-cycles-backend
1,118,336,816,068      instructions              #    0.78  insns per cycle          (75.01%)
249,644,142,804       branches               #   389.218 M/sec                (75.01%)
7,791,449,769       branch-misses            #  3.12% of all branches          (75.01%)
10.003794539 seconds time elapsed</not></not>

這裡一個關鍵的測量指標是每個週期指令(即IPC),該度量指標顯示了我們在每個CPU時脈週期平均完成了多少個指令。簡單來說,這個數值越高越好。上面例子中的0.78聽起來不賴(78%的時間段處於忙碌狀態);但如果你意識到該處理器的最高速度下IPC是4.0,就不這麼認為了。這又叫4-wide,是指指令取出/解碼路徑。這意味著,CPU每個時鐘週期可以retire(完成)四個指令。所以,在4-wide系統上IPC為0.78,代表CPU的運行速度是其最高速度的19.5%。新的英特爾Skylake處理器是5-wide。

你可以用來進一步鑽研的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中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn