作者：小胖前言

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

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

1?理解CPU平均負(fù)載

啥是CPU平均負(fù)載呢？

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

# cat /proc/loadavg
I.33 3.26 3.49 6/434 10737解釋說明：3.33 3.26 3.49 最近1,5,15分鐘平均進(jìn)程數(shù)
6/434 正在運(yùn)行進(jìn)程數(shù)6 當(dāng)前進(jìn)程總數(shù)434(含線程數(shù))10737 最后運(yùn)行進(jìn)程PID嚴(yán)肅點(diǎn)說平均負(fù)載是指：某段時間內(nèi)，內(nèi)核標(biāo)記為可運(yùn)行狀態(tài)或不可中斷狀態(tài)的平均進(jìn)程數(shù)。

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

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

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

打個比方

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

Load=0?? 隧道無車

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

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

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

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

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

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

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

2?理解CPU使用率

看完CPU負(fù)載，咱接著搗鼓下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來計(jì)算

# 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值為負(fù)進(jìn)程

nice[13676] : 低優(yōu)先級用戶態(tài) CPU 時間，也就是進(jìn)程的 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]：當(dāng)系統(tǒng)運(yùn)行在虛擬機(jī)時，被其他虛擬機(jī)搶占的CPU時間

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

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

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

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

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

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

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

[procs_running]：當(dāng)前運(yùn)行隊(duì)列的任務(wù)的數(shù)目。

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

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

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

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

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

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

perf小試牛刀

17985# perf top –g –p

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

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

詳細(xì)參考? ?http://www.brendangregg.com/flamegraphs.html

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

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

# 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已按照進(jìn)程cpu使用率排序遇到這類奇怪問題，有一些思路可以嘗試下：

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

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

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

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

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

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

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

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

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

(3)?nice調(diào)整：調(diào)整進(jìn)程的nice值，提高核心業(yè)務(wù)進(jìn)程的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負(fù)載、使用率的問題有了更深刻的認(rèn)識！這些運(yùn)維小彩蛋還有很多、藏得很深，如果有更好的思路經(jīng)驗(yàn)，也可以寄信給小胖，一起學(xué)習(xí)酷炫！近期文章

圖說k8s

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

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

nginx的location if是如何工作的

基友的服務(wù)器又被黑了

DevSecOps簡述

END

---

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

你是個有眼光的人！

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

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

?

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

總結(jié)

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

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