作者：小胖前言

凌晨一點，正整著炸雞的小胖，微信一呼“你的服務器CPU持續超載 … “

麻溜的連上服務器，先把CPU負載摁下來。仔細一想，最近1分鐘平均負載很大，但CPU利用率卻≤30%，不經陷入了深思，打開學習之門…

1?理解CPU平均負載

啥是CPU平均負載呢？

日常運維我們常用uptime或top命令查看系統當前負載，也可以使用 cat /proc/loadavg# uptime16:04:00 up 6 days, 19 min, 1 user, load average: 3.13, 3.25, 3.50 最近1,5,15分鐘平均負載

# cat /proc/loadavg
I.33 3.26 3.49 6/434 10737解釋說明：3.33 3.26 3.49 最近1,5,15分鐘平均進程數
6/434 正在運行進程數6 當前進程總數434(含線程數)10737 最后運行進程PID嚴肅點說平均負載是指：某段時間內，內核標記為可運行狀態或不可中斷狀態的平均進程數。

(1)?可運行狀態：正在使用CPU或等待CPU，即R狀態進程(Running或Runnable)

(2)?不可中斷狀態：等待某種資源可用(通常是I/O)，即D狀態進程(不含wait狀態)

具體算法在 /usr/src/kernels/${內核版本}/include/linux/sched.h 函數CALC_LOAD(load,exp,n)

打個比方

以單核CPU為例，單核CPU就像一條單行隧道，每個進程是行駛的小汽車。

Load=0?? 隧道無車

Load=0.5 ?隧道有車不多，順暢

Load=1.0??? 隧道滿載，整齊不擁塞

Load=1.7 ?隧道過載，有車等待塞車

小胖不禁發問 平均負載究竟多少比較合理？

(1)?原理上講對于多核CPU，負載均值是基于CPU邏輯核數決定的；參考同胞經驗值，一般認為單個核心負載0.7是警戒線，例如16核警戒線為16*0.7=11.2

(2)?實際業務對CPU需求各不相同，有些業務系統常年低負載/高負載，比較合理的做法是分析歷史負載數據和趨勢變化設置警戒線

(3)?綜合分析最近1/5/15分鐘系統平均負載，如果三個值相近則說明系統平穩；如果最近1分鐘負載大、最近15分鐘負載小，則可能只是短暫業務波峰

2?理解CPU使用率

看完CPU負載，咱接著搗鼓下CPU使用率又是啥？

先敲下top命令瞅瞅

# top
top - 09:44:51 up 188 days, 23:26, 5 users, load average: 1.03, 1.62, 1.82Tasks: 829 total, 1 running, 597 sleeping, 0 stopped, 1 zombie
Cpu(s): 2.7%us, 0.6%sy, 0.0%ni, 96.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

CPU使用率(算法)是指：單位時間內CPU繁忙情況，可以通過 /proc/stat來計算

# cat /proc/stat
cat /proc/stat |head -10cpu 2151316982 13676 447705255 75666027843 24397883 0 21422133 0 0 0cpu0 133476771 224 19023291 1464635099 1418955 0 5724087 0 0 0…
intr 72766406248 237 0 0 1 ...
ctxt 328779743449btime 1559701088processes 1262614693procs_running 3procs_blocked 0softirq 106621687400 21 557059987 6834440 …CPU行數據說明(以cpu第一行為例)

user[2151316982] :?用戶態的CPU時間(單位：jiffies?= 0.01秒) ，不包含 nice值為負進程

nice[13676] : 低優先級用戶態 CPU 時間，也就是進程的 nice 值被調整為 1-19 之間時的 CPU 時間。這里注意，nice 可取值范圍是 -20 到 19，數值越大，優先級反而越低。

system[447705255]: 內核態時間

idle[75666027843]:?除IO等待時間以外其它等待時間

iowait[24397883] : IO等待時間

irq[0]: 處理硬中斷時間

softirq[21422133]: 處理軟中斷時間

steal[0]：當系統運行在虛擬機時，被其他虛擬機搶占的CPU時間

guest[0]：虛擬化運行其他操作系統的時間，也就是運行虛擬機的 CPU 時間

guest_nice[0]：以低優先級運行虛擬機的時間

CPU時間=user+system+nice+idle+iowait+irq+softirq

[intr]：第一個值為自系統啟動以來，發生的所有的中斷的次數；然后每個數對應一個特定的中斷自系統啟動以來所發生的次數。

[ctxt]：系統啟動以來CPU發生的上下文交換的次數。

[btime]：系統啟動到現在為止的時間，單位為秒。

[processes (total_forks)]：系統啟動以來所創建的任務的個數目。

[procs_running]：當前運行隊列的任務的數目。

[procs_blocked]：當前被阻塞的任務的數目。

Linux進程運行又分用戶態和內核態。CPU使用率通常是指：CPU執行非系統空閑進程的時間/CPU總的執行時間，公式如下：

計算CPU使用率腳本參考 https://blog.51cto.com/13466287/2349823

看了這么多枯燥的文字，小胖想知道CPU平均負載和CPU使用率到底有沒有聯系？

上文提到平均負載統計的是處于可運行狀態和不可中斷狀態的進程數。這包括正在使用CPU的，等待使用CPU的和等待某種資源(比如I/O)的進程。從進程特點看：(1)?CPU密集型進程，會大量真實占用CPU時間分片，負載和使用率均高；(2)?IO密集型進程，平均負載高(等待IO資源)，而使用率不一定高舉個例子：假設某個計算進程，運行期間CPU使用率100%，執行單個進程時，負載1，CPU使用率100%；同時執行2個進程時，負載2，CPU使用率仍100%(需要在不同進程間切換，僅為方便理解、實際切換也有開銷)。原來平均負載和使用率沒有必然聯系，平均負載高可能只是等待繁忙的I/O，可以使用top、ps、pidstat等命令來排查定位。CPU使用率除了進程自身消耗(用戶態、內核態)，還包括對軟硬中斷處理、上下文切換、等待IO資源等。3?CPU使用率過高分析線上CPU使用率/負載飆升，通過top、pidstat等命令一般可以快速定位到進程。那么如何進一步分析是哪段函數 或者哪些系統調用引起的呢？Linux上進程追蹤和調試常見有gdb, strace, perf等等。

(1)?GDB調試時經常需要中斷程序執行(斷點)，以查看執行和上下文，對于線上作業難以接受；(2)?strace和perf都支持運行時追蹤。perf已經成為linux內置性能分析工具，相比strace功能更完善。

perf小試牛刀

17985# perf top –g –p

可以追蹤指定已運行進程的調用關系，最終定位到進程、函數段。

perf + FlameGraph還能生成火焰圖，更直觀、交互的分析程序性能

詳細參考? ?http://www.brendangregg.com/flamegraphs.html

來左邊跟我一起畫個龍，在你終端畫一道火焰紅！想不到還能如此酷炫吧！

小胖還曾遇到過CPU使用率高卻定位不到進程的情況？比如

# top
top - 12:05:48 up 99 days, 14:18, 1 user, load average: 2.48, 2.38, 2.23Tasks: 356 total, 2 running, 175 sleeping, 0 stopped, 0 zombie
Cpu(s): 83.2%us, 1.6%sy, 3.1%ni, 86.9%id, 4.4%wa, 0.0%hi, 3.9%si, 0.0%st
Mem: 65960848k total, 57092092k used, 8868756k free, 340300k buffers
Swap: 12582908k total, 3632460k used, 8950448k free, 1437352k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22248 www 20 0 191m 107m 6440 S 5.3 0.2 336:05.66 nginx
22249 www 20 0 179m 94m 6416 S 3.3 0.1 246:14.41 nginx

備注：此處top已按照進程cpu使用率排序遇到這類奇怪問題，有一些思路可以嘗試下：

(1)?首先使用其他性能分析命令如mpstat、ps等，排除命令自身問題；

(2)?仔細觀察實時統計信息，比如top要打開線程統計，是否有頻繁被調用、執行時間很短的外部程序占用了大量CPU資源；

(3)?仍未定位到，則檢查系統日志/業務進程日志，是否存在異常。曾遇到過業務進程異常無法啟動，被守護進程反復拉起崩潰導致占用大量CPU。

4?CPU優化常見方法經過層層剖析，最終定位到性能問題的瓶頸后，小胖理了下思路，覺得不應該急著操作：

(1)?首先明確是硬件問題，還是軟件問題，比如CPU是否開了節能模式、是否被鎖頻？IO慢導致iowait滿載，通過更換高速硬盤、陣列緩存、程序內存緩沖區是否可以解決？而不是上來就動刀子；軟件問題也需要針對應用程序排查日志、性能分析；

(2)?性能問題通常彼此關聯，可能同時暴露多個性能問題，需要我們抓住核心矛盾；一個水桶無論多高，它盛水的高度取決于其中最低的那塊木板；

(3)?實際優化以業務指標為導向，業務角度關注請求延遲、并發數等指標；運維角度關注CPU負載、使用率等指標！優化前后做好指標的量化和對比。回到CPU負載高本身，我們也從前輩處GET到一些切實可行的軟優化手段：

(1)?優化中斷：默認軟中斷由cpu0處理，通過啟用irqbalance服務 或 配置smp_affinity，將中斷分散到多個cpu核心上，比如針對網卡軟中斷優化；

(2)?cpu綁定：將進程綁定到一個或者多個指定核上，提高cpu緩存命中率，減少上下文切換，最常見的是nginx?cpu綁定

(3)?nice調整：調整進程的nice值，提高核心業務進程的CPU優化級

(4)?CGroup：基于內核cgroup功能來配額資源，包括CPU、內存等

(5)?Numa優化：多CPU架構中，BIOS開啟numa后，使用numactl來優化內存分配，讓CPU盡可能只訪問本地內存

看到這里，相信你和小胖一樣已經對CPU負載、使用率的問題有了更深刻的認識！這些運維小彩蛋還有很多、藏得很深，如果有更好的思路經驗，也可以寄信給小胖，一起學習酷炫！近期文章

圖說k8s

推薦一款簡單易用線上引流測試工具：GoReplay

從內心掙扎到豁然開朗，擁抱MySQL5.7！

nginx的location if是如何工作的

基友的服務器又被黑了

DevSecOps簡述

END

---

全中國只有不到1%?的人關注了運維軍團

你是個有眼光的人！

(由于交流群人數已超100人，需要進群的小伙伴可以添加運維小編的微信：)

如果你喜歡我們的文章，請轉發到朋友圈

?

??公眾號ywjtshare運維軍團?專注運維技術與傳承，分享豐富原創干貨

總結

以上是生活随笔為你收集整理的io密集型和cpu密集型_和小胖一起理解CPU负载和利用率的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。