如何測量linux中的實際CPU使用率？

Question

我知道有一些工具如top和ps用於測量CPU使用率，但他們測量CPU使用率的方式是測量空閑任務未運行的時間。 因此，例如，即使CPU由於高速緩存未命中而導致停頓，這些工具仍將認為CPU被占用。 但是，我想要的是分析工具在停頓期間將CPU視為空閑。 有沒有這樣做的工具？

Answer 1

用於測量CPU使用率的top和ps等工具，...通過測量空閑任務未運行的時間來衡量CPU使用率。

不，他們不測量空閑，他們只是通過/ proc / stat讀取內核對CPU使用率的看法（也嘗試使用vmstat 1工具）。 您是否檢查過系統范圍的用戶+系統時間是否僅由idle ？ 我認為，內核只會導出調度程序的一些統計信息，它會在重新安排時記錄用戶/系統狀態，包括系統計時器和阻塞系統調用（可能是cpuacct_charge的調用者之一，如update_curr - 更新當前任務的運行時統計信息。 ）。

/ proc / stat示例：

cat /proc/stat
cpu  2255 34 2290 22625563 6290 127 456

並通過http://www.linuxhowtos.org/System/procstat.htm進行解碼

第一個“cpu”行匯總​​了所有其他“cpuN”行中的數字。 這些數字表示CPU執行不同類型工作所花費的時間。 時間單位為USER_HZ或Jiffies （通常為百分之一秒）。

列的含義如下，從左到右：

user: normal processes executing in user mode
nice: niced processes executing in user mode
system: processes executing in kernel mode
idle: twiddling thumbs

當我們聽到jiffie時，它意味着調度程序用於獲取數字，而不是估計idle任務（頂部甚至看不到此任務或具有pid 0的任務）。

因此，例如，即使CPU由於高速緩存未命中而導致停頓，這些工具仍將認為CPU被占用。

基本上（當沒有SMT時 ，比如英特爾中的HT），當你的任務由於內存訪問而導致管道停頓（或采用無序的錯誤路徑）時，CPU就會被占用。 操作系統無法運行其他任務，因為任務切換比等待這一檔更加昂貴。

SMT的情況不同，因為有硬件要么在單個硬件上切換兩個邏輯任務，要么（在細粒度SMT中）將它們的指令（微操作）混合到單個流中以在共享硬件上執行。 通常有SMT統計計數器來檢查實際混合。

但是，我想要的是分析工具在停頓期間將CPU視為空閑。 有沒有這樣做的工具？

績效監測單位可能會為此提供有用的事件。 例如， perf stat報告一些（在Sandy Bridge上）

$ perf stat /bin/sleep 10

 Performance counter stats for '/bin/sleep 10':
      0,563759 task-clock                #    0,000 CPUs utilized          
             1 context-switches          #    0,002 M/sec                  
             0 CPU-migrations            #    0,000 M/sec                  
           175 page-faults               #    0,310 M/sec                  
       888 767 cycles                    #    1,577 GHz                    
       568 603 stalled-cycles-frontend   #   63,98% frontend cycles idle   
       445 567 stalled-cycles-backend    #   50,13% backend  cycles idle   
       593 103 instructions              #    0,67  insns per cycle        
                                         #    0,96  stalled cycles per insn
       115 709 branches                  #  205,246 M/sec                  
         7 699 branch-misses             #    6,65% of all branches        

  10,000933734 seconds time elapsed

因此，它表示睡眠10使用了0,5 jiffie（任務時鍾）。它太低而無法計入經典的rusage，並且/ usr / bin / time得到0 jiffie作為任務CPU使用（用戶+系統） ）：$ / usr / bin / time sleep 10 0.00user 0.00system 0：10.00elapsed 0％CPU（0avgtext + 0avgdata 2608maxresident）k 0inputs + 0outputs（0major + 210minor）pagefaults 0swaps

然后執行測量（在PMU的幫助下計數）實際循環和由任務執行的實際指令（以及代表任務的內核） - cycles和instructions行。 睡眠已經使用了888k周期，但只完成了593k有用的指令，平均IPC為0.6-0.7（30-40％的停頓）。 失去了大約300k個周期; 並且在Sandy bridge perf報告它們丟失的地方 - stalled-cycles-*前端事件（解碼器 - CPU不知道由於分支未命中或由於代碼未預取到L1I而執行什么）和后端（不能執行因為指令需要來自內存的某些數據，這些數據在正確的時間不可用 - 內存停止。

為什么我們在沒有任何指令執行的情況下應該只有300k個周期時會在CPU內看到更多停頓？ 這是因為現代處理器通常超標量且無序 - 它們可以在每個CPU時鍾周期開始執行多個指令，甚至可以對它們進行重新排序。 如果您想查看執行端口利用率，請嘗試使用Andi Kleen的pmu-tools中的 ocperf （perf wrapper）和一些有關其PMU計數器的英特爾手冊。 還有toplev.py腳本來“ 識別工作負載的微架構瓶頸 ”，而無需手動選擇英特爾事件。