近很多人反映說電腦開機時就進入死機狀態了，查看CPU的使用情況后發現CPU的使用率已經飆升至100%了。現在我為大家做專業技術解答，我們都知道，CPU不但是電腦的運算核心也是電腦的控制核心，一臺電腦中最重要的一個硬件就是CPU硬件，可以說CPU硬件決定了電腦的綜合性能。CPU使用率高而導致電腦運行不流暢的朋友應該對CPU的重要性深有體會了，那電腦為何開機后CPU占用率直接飆升到100%了呢？

很多人不明白這CPU使用率100%的真正含義是什么，CPU0%~100%就是CPU的性能數值，百分比數字越小，那該CPU在電腦中表現的性能就越高，當CPU使用率高達100%時證明CPU在電腦中的性能已經火力全開了，CPU高負載運行已經達到了該CPU性能的極限點了，正常CPU一般資源使用不會達到100%，CPU資源被100%占用的電腦也不能正常使用。電腦開機后CPU使用率立刻達到100%和電腦開機后使用一段時間CPU使用率再達到100%是不一樣的故障，此外，電腦聯網和不聯網的狀態下CPU使用率100%故障又不一樣。

電腦開機后CPU使用率立刻飆升到100%

電腦開機后的狀態是裸機狀態，開機進系統后CPU使用率持續飆升甚至直接飆升到100%了，那這電腦的操作系統類型選錯了，準確的說就是：你的電腦硬件配置帶不動你所安裝的操作系統。

電腦開機后一段時間了，CPU使用率漸漸飆升直至飆升到100%

這種情況下我們需要考慮兩個因素，第一因素就是CPU的散熱問題，第二就是操作系統感染木馬病毒程序。電腦在使用時CPU就會處理數據，處理數據會導致CPU發熱，如果CPU的自身熱量無法被散熱器冷卻時，CPU就會被迫降低運行頻率，CPU的性能跟頻率直接掛鉤，CPU的性能大幅度降低后，幾個小程序都能使CPU滿載。性能再好的CPU也經不起木馬病毒程序的摧毀，電腦病毒程序無限制自我復制，CPU的資源一定會被全部占滿。

低配電腦高需求操作電腦可直接導致電腦CPU使用率飆升到100%

這意思就是低端配置的電腦就要干低需求的操作，什么需求的用戶選什么需求配置的電腦，拿辦公配置的電腦裝3D MAX制圖軟件還要渲染的話，那CPU使用率不直接飆升至100%了嗎？CPU占用率飆升到100%后，你的電腦真無法“動彈”了，可以說操作一步卡N步。

本文原創版權所有，未經允許禁止侵權盜用，一經發現維權到底，全網監測侵權必究。原創作者：王李軍，本文作者：王李軍。最后感謝大家的關注與閱讀評論，記住，點關注不迷路，下期我們再見！

PU使用率（CPU utilization）直觀顯示了運行程序占用的CPU資源，使用率越高，說明你的機器在這個時間上運行了很多程序，一般情況下，CPU占了100%的話我們的電腦就會明顯慢下來。

但你知道嗎？我們用來衡量CPU使用率的這一指標具有極大的誤導性，而且一年比一年來得誤人子弟。

Brendan Gregg是Netflix的高級性能架構師，他在那里做大規模計算機性能設計、分析和調優。他是《Systems Performance》等技術書的作者，曾獲得過2013年USENIX LISA大獎。

5月9日，他在個人博客發表了一篇《CPU Utilization is Wrong（CPU使用率是錯誤的）》博文，指出CPU使用率已成為一個極具誤導性的度量指標。

你可能認為90%的CPU使用率意味著：

而實際上它可能意味著：

停滯（stalled）意味著處理器在處理指令方面處于停滯狀態，通常是由于處理器在等待內存輸入/輸出，這在現實生活生產中時刻存在，但大多數人渾然不知。

Brendan Gregg表示，現如今，CPU的速度已變得比主內存快得多，如果你看到數值很高的%CPU，可能認為處理器是瓶頸，而實際上那些DRAM模組才是瓶頸。

了解你的多少CPU處于停滯狀態可以指導減少代碼或減少內存輸入/輸出之間的性能調優工作。誰要是在關注CPU性能，尤其是在根據CPU自動擴展資源的云，如果知道%CPU中停滯的部分，那將大有益處。

當然，Brendan Gregg是從開發人員角度闡述的，對于普通消費者，CPU使用率依然是個簡單好用的性能展示工具。

入容器中top，雖然看到的PID是容器的，但是%Cpu的統計信息卻是宿主機的。

如圖

原理

進程的cpu使用率是如何計算出來的？

每個進程的狀態是放在文件里的，在/proc目錄下，每個進程有自己pid命名的文件夾，

比如我現在這個jenkins的docker進程，通過inspect查詢到Pid是30134

我們繼續查看/proc/30134下的文件。

里面的文件比較多，我們現在只關心stat文件

[root@paas-m-k8s-node-1 30134]# cat stat30134 (tini) S 30112 30134 30134 0 -1 1077944576 1639 0 0 0 244 934 0 0 20 0 1 0 2352840503 2514944 114 18446744073709551615 94288423874560 94288423890205 140731692225440 140731692224320 139648449412143 0 0 3145728 0 18446744072548467014 0 0 17 12 0 0 0 0 0 94288423901968 94288423904395 94288443621376 140731692228014 140731692228057 140731692228057 140731692228586 0

這個stat文件是進程的實時狀態信息，實時輸出了進程的狀態信息，比如進程的運行態（Running 還是

Sleeping）、父進程 PID、進程優先級、進程使用的內存等等總共 50 多項。

這些指標每個空格隔開是一項，現在就看第14項時utime，即進程的用戶態部分占用的cpu時間片。244

第15項是 stime，即進程的內核態部分占用的cpu時間片。934

需要注意的是，utime 和 stime 都是一個累計值，也就是說從進程啟動開始，這兩個值就是一直在累積增長的

然后根據這兩個值來計算進程的cpu使用率。具體的計算公式就不講了。

上面是單個進程的cpu使用計算，那整個系統的cpu數據在哪？

在/proc/stat文件

明白了

在容器里top看到的是宿主機的cpu的原因就是，top查的是/proc/stat文件，這個文件是反應整個宿主機的狀態信息的，不是單個容器的。

有什么辦法嗎

我們知道每個容器有自己的cpu cgroup控制組，在這個控制組的目錄下有很多文件

比如我現在的容器cgroup的目錄是

其中有個cpuacct.stat文件，就有整個容器的cpu信息

注意，這里的user和system的信息也是累計值

所以我們可以每秒獲取一次，通過計算得到實時的cpu使用率。

單臺節點上容器數量小于1000，計算周期位10s的情況下，計算資源的消耗很小。

是不是還是感覺很麻煩，下一篇分享一個小工具幫我們解決這個問題。