作者：小胖前言

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

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

1?理解CPU平均負載

啥是CPU平均負載呢？

日常運維我們常用uptime或top命令查看系統(tǒng)當前負載，也可以使用 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分鐘平均進程數(shù)
6/434 正在運行進程數(shù)6 當前進程總數(shù)434(含線程數(shù))10737 最后運行進程PID嚴肅點說平均負載是指：某段時間內(nèi)，內(nèi)核標記為可運行狀態(tài)或不可中斷狀態(tài)的平均進程數(shù)。

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

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

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

打個比方

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

Load=0?? 隧道無車

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

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

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

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

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

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

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

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使用率(算法)是指：單位時間內(nèi)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行數(shù)據(jù)說明(以cpu第一行為例)

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

nice[13676] : 低優(yōu)先級用戶態(tài) CPU 時間，也就是進程的 nice 值被調(diào)整為 1-19 之間時的 CPU 時間。這里注意，nice 可取值范圍是 -20 到 19，數(shù)值越大，優(yōu)先級反而越低。

system[447705255]: 內(nèi)核態(tài)時間

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

iowait[24397883] : IO等待時間

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

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

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

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

guest_nice[0]：以低優(yōu)先級運行虛擬機的時間

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

[intr]：第一個值為自系統(tǒng)啟動以來，發(fā)生的所有的中斷的次數(shù)；然后每個數(shù)對應一個特定的中斷自系統(tǒng)啟動以來所發(fā)生的次數(shù)。

[ctxt]：系統(tǒng)啟動以來CPU發(fā)生的上下文交換的次數(shù)。

[btime]：系統(tǒng)啟動到現(xiàn)在為止的時間，單位為秒。

[processes (total_forks)]：系統(tǒng)啟動以來所創(chuàng)建的任務的個數(shù)目。

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

[procs_blocked]：當前被阻塞的任務的數(shù)目。

Linux進程運行又分用戶態(tài)和內(nèi)核態(tài)。CPU使用率通常是指：CPU執(zhí)行非系統(tǒng)空閑進程的時間/CPU總的執(zhí)行時間，公式如下：

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

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

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

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

perf小試牛刀

17985# perf top –g –p

可以追蹤指定已運行進程的調(diào)用關(guān)系，最終定位到進程、函數(shù)段。

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)?仔細觀察實時統(tǒng)計信息，比如top要打開線程統(tǒng)計，是否有頻繁被調(diào)用、執(zhí)行時間很短的外部程序占用了大量CPU資源；

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

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

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

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

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

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

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

(3)?nice調(diào)整：調(diào)整進程的nice值，提高核心業(yè)務進程的CPU優(yōu)化級

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

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

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

圖說k8s

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

從內(nèi)心掙扎到豁然開朗，擁抱MySQL5.7！

nginx的location if是如何工作的

基友的服務器又被黑了

DevSecOps簡述

END

---

全中國只有不到1%?的人關(guān)注了運維軍團

你是個有眼光的人！

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

如果你喜歡我們的文章，請轉(zhuǎn)發(fā)到朋友圈

?

??公眾號ywjtshare運維軍團?專注運維技術(shù)與傳承，分享豐富原創(chuàng)干貨

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。