平均負載
1. 理解平均負載
??平均負載對很多人來說既熟悉又陌生撞鹉，那我們?nèi)绾卫斫夂陀^測這個最常見、也是最重要的系統(tǒng)指標(biāo)呢颖侄？
??平均負載是指單位時間內(nèi)鸟雏，系統(tǒng)處于可運行狀態(tài)和不可中斷狀態(tài)的平均進程數(shù)量，也就是平均活躍進程數(shù)览祖。
??可運行狀態(tài)：指正在使用或者正在等待 CPU 的進程孝鹊，也就是我們常用 ps 命令看到的，處于 R 狀態(tài)（Running 或 Runnable）的進程展蒂。
??不可中斷狀態(tài)：指的是正處于內(nèi)核態(tài)關(guān)鍵流程中的進程又活，并且這些流程是不可打斷的，比如最常見的是等待硬件設(shè)備的 I/O 響應(yīng)锰悼，也就是我們在 ps 命令中看到的 D 狀態(tài)（Uninterruptible Sleep柳骄，也稱為 Disk Sleep）的進程。不可中斷狀態(tài)實際上是系統(tǒng)對進程和硬件設(shè)備的一種保護機制箕般，比如當(dāng)一個進程向磁盤寫入數(shù)據(jù)時耐薯，在得到磁盤回復(fù)之前，它是不能被其他進程或者中斷打斷的丝里，此時進程就處于不可中斷狀態(tài)曲初，否則會處于磁盤數(shù)據(jù)和進程數(shù)據(jù)不一致的情況。
??因此杯聚，你可以簡單的將平均負載理解為平均活躍進程數(shù)量臼婆，那么最理想的狀態(tài)，就是每個CPU上剛好運行一個進程械媒，這樣每個CPU都得到了充分利用目锭。在實際的情況中，平均負載為多少時合理呢纷捞？多大說明系統(tǒng)負載高痢虹？多小說明負載很低呢？
??一般情況下主儡，當(dāng)平均負載高于CPU數(shù)量的70%的時候奖唯，你就應(yīng)該分析排查負載高的問題了，一旦負載變高糜值，就可能導(dǎo)致進程響應(yīng)變慢丰捷，進而影響正常的功能坯墨，當(dāng)然這個數(shù)字并不是絕對的，最推薦的方式病往，還是監(jiān)控系統(tǒng)的平均負載捣染，然后根據(jù)更多的歷史數(shù)據(jù)，判斷負載的變化趨勢停巷，當(dāng)發(fā)現(xiàn)負載有明顯的升高趨勢時耍攘，再去分析和調(diào)查。
??現(xiàn)實工作中畔勤，我們會把平均負載和CPU使用率混淆蕾各，讓我們重新回顧一下平均負載的概念：平均負載是指單位時間內(nèi)，系統(tǒng)處于可運行狀態(tài)和不可中斷狀態(tài)的平均進程數(shù)量庆揪。也就是說它不僅包含正在使用CPU的進程式曲，還包括等待CPU和等待IO的進程。而CPU使用率表示單位時間內(nèi)缸榛，非空閑狀態(tài)所占的比例吝羞，比如：
-
CPU密集型，使用大量的CPU會使得平均負載升高仔掸。 -
IO密集型脆贵，等待IO也會導(dǎo)致平均負載升高，但是此時CPU使用率不一定高起暮。 - 大量等待
CPU進程調(diào)度也會導(dǎo)致平均負載升高，此時的CPU使用率也會比較高会烙。
2. 平均負載分析
在分析平均負載之前负懦，先簡單的介紹一下 sysstat，它包含了常用的Linux 性能工具柏腻，用來監(jiān)控和分析系統(tǒng)的性能纸厉，我們會用到其中的 mpstat 和 pidstat。
??
mpstat是一個常用的CPU性能分析工具五嫂，用來實時查看每個CPU的性能指標(biāo), 以及所有CPU的平均指標(biāo)颗品。
??pistat是一個常用的進程性能分析工具，用來實時查看進程的CPU沃缘、內(nèi)存躯枢、IO以及上下文切換等性能指標(biāo)。
??在分析平均負載之前槐臀，我們可以通過 lscpu 命令查看當(dāng)前機器的CPU信息锄蹂。
$ lscpu
CPU(s): 1
...
1. 場景一: CPU密集進程
- 通過
uptime命令查看平均負載的變化情況(過去 1 分鐘、5 分鐘水慨、15 分鐘),由下圖終端的結(jié)果來看得糜，平均負載時逐步增高的敬扛。
$ watch -d uptime
..., load average: 1.00, 0.75, 0.39
- 通過
mpstat查看CPU使用率的變化情況，由下圖執(zhí)行結(jié)果來看朝抖，有個線程的CPU占用率為100%, 但是iowait只有 0 啥箭，說明平均負載的升高是因為CPU的利用率較高。
$ mpstat -P ALL 5 1
08:42:30 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:42:35 PM all 0.50 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:42:35 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:42:35 PM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
- 通過
pidstat查看進程的性能指標(biāo)如下治宣，我們可以看到到底為哪個進程導(dǎo)致CPU利用率升高捉蚤。
$ pidstat -u 5 1
08:51:25 PM UID PID %usr %system %guest %CPU CPU Command
08:51:31 PM 1002 1024 100.00 0.00 0.00 100.00 1 ***
分析步驟總結(jié)
- 確定服務(wù)器的核心數(shù)量，通過
uptime命令觀察平均負載的趨勢走向炼七。 - 通過
mpstat命令服務(wù)器的運行情況, 包括cpu利用率缆巧、io等待、用戶態(tài)豌拙、系統(tǒng)態(tài)陕悬、爭用CPU所占時間 等各個指標(biāo)所占比例等等。 - 通過
pidstat命令查看哪個進程所占的cpu或者iowait高按傅，又或者是系統(tǒng)運行進程超出了cpu的運行能力, 導(dǎo)致cpu過載捉超。
CPU上下文切換
??Linux 是一個多任務(wù)操作系統(tǒng)，它支持遠大于 CPU 數(shù)量的任務(wù)同時運行唯绍。當(dāng)然拼岳，這些任務(wù)實際上并不是真的在同時運行，而是因為系統(tǒng)在很短的時間內(nèi)况芒，將 CPU 輪流分配給它們惜纸，而每個人任務(wù)執(zhí)行之前，CPU都必需知道該任務(wù)所需的數(shù)據(jù)從哪里加載绝骚，又從哪里開始運行（CPU寄存器和程序計數(shù)器）耐版。CPU上下文切換實際上就是把前一個任務(wù)的上下文保存起來，然后加載當(dāng)前正在準備執(zhí)行的任務(wù)的上下文到寄存器和計數(shù)器中压汪，運行新任務(wù)粪牲。
??實際CPU的上下文切換可以分為幾個不同的場景，進程上下文切換止剖、線程上下文切換以及中斷上下文切換腺阳。
進程上下文切換
?? Linux 特權(quán)等級，將進程的運行空間分為內(nèi)核空間和用戶空間穿香，內(nèi)核空間具有最高的訪問權(quán)限亭引；而用戶空間只能訪問受限的資源，不能直接訪問內(nèi)存等硬件設(shè)備扔水，必需通過系統(tǒng)調(diào)用陷入內(nèi)核中痛侍，才能訪問這些特權(quán)資源。從用戶態(tài)到內(nèi)核態(tài)的轉(zhuǎn)變，是通過系統(tǒng)調(diào)用完成的主届。比如我們的程序訪問文件內(nèi)容就需要進行系統(tǒng)調(diào)用赵哲，首先通過系統(tǒng)調(diào)用打開文件，將內(nèi)容讀取到內(nèi)核空間君丁，拷貝到用戶空間之后才能被程序處理枫夺。
??由此可見，系統(tǒng)調(diào)用的時候會發(fā)生了CPU上下文切換绘闷。 CPU寄存器里原來用戶態(tài)程序的上下文信息需要先保存起來橡庞，為了執(zhí)行內(nèi)核態(tài)代碼，加載內(nèi)核代碼的上下文印蔗，運行內(nèi)核任務(wù)扒最，系統(tǒng)調(diào)用結(jié)束之后，需要切換到用戶空間华嘹。所以吧趣，一次系統(tǒng)調(diào)用，會發(fā)生兩次CPU上下文切換耙厚。
??系統(tǒng)調(diào)用過程中强挫，并不會涉及到虛擬內(nèi)存等進程用戶態(tài)的資源，也不會切換進程薛躬。這跟我們通常所說的進程上下文切換是不一樣的俯渤，進程上下文切換指的是從一個進程切換到另一個進程，而系統(tǒng)調(diào)用一直是一個進程型宝，所以通常被稱為特權(quán)模式切換八匠，而不是上下文切換。
??進程是由內(nèi)核來管理和調(diào)度的诡曙，進程的切換只能發(fā)生在內(nèi)核態(tài)柄错。所以芜抒，進程的上下文不僅包括了虛擬內(nèi)存、棧闯狱、全局變量等用戶空間的資源渊涝，還包括了內(nèi)核堆棧慎璧、寄存器等內(nèi)核空間的狀態(tài)。因此進程上下文切換比系統(tǒng)調(diào)用多了一步跨释，保存當(dāng)前進程的內(nèi)核狀態(tài)和CPU寄存器之前胸私，需要先把該進程的虛擬內(nèi)存、棧等保存起來鳖谈。
究竟什么時候會切換進程上下文呢岁疼？
- 操作系統(tǒng)為了保證公平調(diào)度，
CPU時間被劃分為一段段的時間片，然后輪流分配給各個進程捷绒，當(dāng)某個進程的時間片耗盡之后瑰排，會被系統(tǒng)掛起，切換到其他等待CPU的進程運行暖侨。 - 進程在資源不足的情況下椭住，要等到資源滿足之后才可以運行，這個時候也會被掛起字逗，由系統(tǒng)調(diào)度其他進程京郑。
- 進程通過
sleep函數(shù)將自己主動掛起。 - 優(yōu)先級較高的進程運行時葫掉，為了保證高優(yōu)先級的先被運行些举，當(dāng)前進程會被掛起。
- 發(fā)生硬件中斷時俭厚，
CPU進程會中斷掛起户魏，轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務(wù)進程。
線程上下文切換
??線程是調(diào)度的基本單位套腹，而進程則是資源擁有的基本單位绪抛。內(nèi)核中的任務(wù)調(diào)度，實際調(diào)度的對象時線程电禀，而進程只是給線程提供了虛擬內(nèi)存幢码、全局變量等資源。
- 當(dāng)進程只有一個線程時尖飞，進程等于線程症副。
- 當(dāng)進程有多個線程時，全局變量等線程公共資源是不用修改的政基，而線程自己的私有數(shù)據(jù)贞铣，比如棧和寄存器，也是需要保存的沮明。
??如果為第一種辕坝，線程上下文切換過程和進程切換相同，對于第二種荐健，由于不需要保存公共資源酱畅，所以同進程內(nèi)的線程切換，要比多進程間的切換消耗更小江场。
中斷上下文切換
??為了快速響應(yīng)硬件的事件纺酸，中斷處理會打斷進程的正常調(diào)度和執(zhí)行，轉(zhuǎn)而調(diào)用中斷處理程序址否，響應(yīng)設(shè)備事件餐蔬，而在打斷進程的正常調(diào)度之前，需要保存當(dāng)前進程的狀態(tài)。跟進程上下文不同樊诺，中斷并不涉及進程的用戶態(tài)仗考，所以不需要保存和恢復(fù)這個進程的虛擬內(nèi)存、全局變量等用戶態(tài)資源啄骇。中斷上下文痴鳄，其實只包括內(nèi)核態(tài)中斷服務(wù)程序執(zhí)行所必需的狀態(tài)，包括 CPU 寄存器缸夹、內(nèi)核堆棧痪寻、硬件中斷參數(shù)等。
??對同一個 CPU 來說虽惭，中斷處理比進程擁有更高的優(yōu)先級橡类，所以中斷上下文切換并不會與進程上下文切換同時發(fā)生。由于中斷會打斷正常進程的調(diào)度和執(zhí)行芽唇，所以大部分中斷處理程序都短小精悍顾画，以便盡可能快的執(zhí)行結(jié)束，但是中斷上下文切換也需要消耗 CPU匆笤，切換次數(shù)過多也會耗費大量的 CPU研侣，甚至嚴重降低系統(tǒng)的整體性能。所以炮捧，當(dāng)你發(fā)現(xiàn)中斷次數(shù)過多時庶诡，就需要注意去排查它是否會給你的系統(tǒng)帶來嚴重的性能問題。
查看上下文切換情況
??過多的上下文切換咆课，會將資源耗費在寄存器末誓、內(nèi)核棧以及虛擬內(nèi)存的數(shù)據(jù)的保存和恢復(fù)上，縮短進程真正的執(zhí)行時間书蚪，而上下文的切換包括兩種：
- 自愿上下文切換：指進程無法獲取所需要的資源喇澡，導(dǎo)致的上下文切換，比如
IO殊校、內(nèi)存等系統(tǒng)資源不足晴玖。 - 非自愿上下文切換：指的是進程的時間片已經(jīng)到期，被系統(tǒng)強制調(diào)度發(fā)生为流。
??我們主要通過vmstat查詢系統(tǒng)的上下文切換情況, 主要特別關(guān)注以下四列內(nèi)容:
-
r： 就緒隊列的長度窜醉，表示運行或者等待CPU的進程數(shù)量。 -
b：表示不可中斷睡眠狀態(tài)的進程數(shù)艺谆。 -
in：每秒中斷次數(shù)。 -
cs： 每秒上下文切換的次數(shù)拜英。
場景: 案例分析
- 首先通過
vmstat工具 觀察系統(tǒng)的上下文切換情況：
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
11 0 0 323460 140952 1159544 0 0 2 8 74 65 1 1 99 0 0
9 0 0 323460 140952 1159544 0 0 0 0 1550 942091 39 61 0 0 0
??關(guān)注內(nèi)容：上下文切換次數(shù)：由 65 升高為 942091静汤；有序隊列的長度 8 已經(jīng)遠遠超過了系統(tǒng)的CPU個數(shù)（2）；CPU使用率（us + sy）已經(jīng)到達了 100%；中斷次數(shù)也提升到了 1550 次虫给。
綜合這些指標(biāo)我們可以知道系統(tǒng)的就緒隊列過長藤抡，導(dǎo)致大量的上下文切換，而上下文切換又導(dǎo)致了CPU 占用率的升高抹估。
- 通過
pidstat查看CPU和進程上下文切換情況：
$ pidstat -w -u 1
02:22:06 PM UID PID %usr %system %guest %wait %CPU CPU Command
02:22:07 PM 0 1058 1.00 0.00 0.00 0.00 1.00 0 AliYunDun
02:22:07 PM 0 17861 38.00 61.00 0.00 0.00 99.00 0 sysbench
02:22:06 PM UID PID cswch/s nvcswch/s Command
02:22:07 PM 0 11 1.00 0.00 ksoftirqd/0
02:22:07 PM 0 12 42.00 0.00 rcu_sched
02:22:07 PM 0 22 2.00 0.00 kcompactd0
02:22:07 PM 0 145 5.00 0.00 load_calc
02:22:07 PM 32 498 1.00 0.00 rpcbind
02:22:07 PM 1003 569 1.00 0.00 memcached
02:22:07 PM 0 732 1.00 0.00 php-fpm
02:22:07 PM 1002 790 10.00 0.00 redis-server
02:22:07 PM 0 1058 11.00 0.00 AliYunDun
02:22:07 PM 0 1120 31.00 0.00 AliYunDunMonito
02:22:07 PM 0 5201 10.00 0.00 AliSecGuard
02:22:07 PM 0 17678 1.00 0.00 sshd
02:22:07 PM 0 17857 1.00 0.00 kworker/u4:1-events_unbound
02:22:07 PM 0 17860 6.00 0.00 kworker/0:1-events
02:22:07 PM 0 17890 1.00 0.00 pidstat
從輸出發(fā)現(xiàn)缠黍，CPU使用率的升高是因為 sysbench導(dǎo)致的，但是上下文切換是來自其他的進程药蜻，不過圖中輸出的上下文切換次數(shù)瓷式，明顯比 942091 小的多，講到的幾種上下文切換場景语泽。其中提到贸典， Linux 調(diào)度的基本單位實際上是線程，那么踱卵，是不是 pidstat 忽略了線程的數(shù)據(jù)呢廊驼？通過 man pidstat 的描述，實際上默認展示的是進程數(shù)據(jù)惋砂，所以我們需要再加上 -t 參數(shù)：
$ pidstat -wt 1
02:30:37 PM UID TGID TID cswch/s nvcswch/s Command
02:30:39 PM 0 - 17944 12110.71 74812.50 |__sysbench
02:30:39 PM 0 - 17945 13327.68 71582.14 |__sysbench
02:30:39 PM 0 - 17946 10166.96 76762.50 |__sysbench
02:30:39 PM 0 - 17947 5872.32 88392.86 |__sysbench
02:30:39 PM 0 - 17948 14217.86 68983.93 |__sysbench
……
??雖然 sysbench 進程的上下文切換次數(shù)不多妒挎，但是它的子進程的上下文次數(shù)卻又很多，所以罪魁禍首就是過多的 sysbench 線程西饵。那四個關(guān)注指標(biāo)中的中斷次數(shù)又如何解釋呢酝掩？到底是什么類型的中斷上升了呢？
我們可以通過 /proc/interrupts 這個只讀文件中讀取中斷發(fā)生的類型罗标，通過下列命令觀察中斷的變化情況:
$ watch -d cat /proc/interrupts
分析步驟和總結(jié)
??1. 通過 vmstat 查看服務(wù)的總體狀態(tài)庸队，包括CPU 使用率、上下文切換次數(shù)闯割、有序隊列和中斷次數(shù)（四個關(guān)鍵指標(biāo)）彻消。
??2. 通過 pidstat 查看進程的上下文切換情況，定位到進程或者線程宙拉。
??3. 通過查看/proc/interrupts 文件確定中斷發(fā)生的類型和次數(shù)宾尚。
??自愿上下文切換次數(shù)變多，說明進程在等待資源谢澈，有可能發(fā)生了 io或者其他問題煌贴；非自愿上下文切換次數(shù)變多，說明進程都在爭搶CPU锥忿，說明CPU變成了瓶頸牛郑；中斷次數(shù)變多，說明 CPU被中斷處理程序占用敬鬓，需要查看/proc/interrupts 文件分析具體的中斷類型淹朋。
CPU達到100%應(yīng)該怎么辦
如何查看CPU使用率
查看CPU的使用率笙各，第一反應(yīng)肯定是top和 ps工具：
-
top：現(xiàn)實系統(tǒng)總體的CPU和內(nèi)存情況，以及各個進程的資源使用情況础芍。 -
ps：顯示每個進程的資源使用情況杈抢。
比如下列就為top命令的輸出情況：
$ top
top - 15:29:09 up 3 days, 19:13, 2 users, load average: 0.02, 0.02, 0.49
Tasks: 135 total, 3 running, 132 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 6.7 sy, 0.0 ni, 93.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 1887.8 total, 304.7 free, 300.5 used, 1282.5 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1400.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 104512 12152 9112 S 0.0 0.6 0:04.57 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
??其中第三行就為系統(tǒng)的 CPU使用率，不過默認展示的所有 CPU的平均值仑性，只需要按下數(shù)字 1惶楼，就可以切換到每個CPU的使用率了。下方空白行之后是進程的實時信息诊杆，每個進程都有一個 %CPU列歼捐，標(biāo)識該進程的 CPU使用情況，不過 top工具并沒有細分進程的用戶態(tài)CPU還是內(nèi)核態(tài)CPU刽辙，可以使用 pidstat工具查看更加詳細的信息窥岩。
$ pidstat 1 5
進程號 用戶態(tài) 系統(tǒng)態(tài) 運行虛擬機 等待CPU 總的
03:40:28 PM UID PID %usr %system %guest %wait %CPU CPU Command
03:40:29 PM 0 1058 1.00 0.00 0.00 0.00 1.00 0 AliYunDun
03:40:29 PM 0 1120 1.00 0.00 0.00 0.00 1.00 0 AliYunDunMonito
03:40:29 PM 0 21088 0.00 1.00 0.00 0.00 1.00 0 pidstat
CPU使用率過高怎么辦
??通過top、ps宰缤、pidstat等工具颂翼，可以輕松的找到CPU使用率較高的進程，那如何找到占用 CPU到底是代碼里的哪個函數(shù)呢慨灭？可以通過 perf 工具來完成朦乏，它是一個基于性能事件采樣為基礎(chǔ)，不僅可以分析系統(tǒng)的各種事件和內(nèi)核性能氧骤，還可以分析指定應(yīng)用程序的性能問題呻疹。
CPU使用率過高，但是無法找到高CPU的應(yīng)用
??系統(tǒng)的CPU使用率筹陵，不僅包含進程用戶態(tài)和內(nèi)核態(tài)的運行刽锤，還包括中斷處理、等待IO以及內(nèi)核線程等朦佩，所以當(dāng)系統(tǒng)的CPU過高時并思，不一定能找到對應(yīng)的高CPU使用率的進程。
??所以语稠，如果通過top命令發(fā)現(xiàn)系統(tǒng)的整體CPU命令很高宋彼，但是無論是根據(jù)下方進程列表的展示還是通過其他的工具(pidstat)查看，都找不到高CPU使用率的進程時仙畦，有可能為下面這些情況：
- 應(yīng)用里直接調(diào)用了其他二進制程序输涕，這些程序的通常運行時間比較短，通過
top工具也不容易發(fā)現(xiàn)慨畸。 - 應(yīng)用本身在不停的崩潰重啟莱坎，而啟動過程的資源初始化，很可能會占用相當(dāng)多的
CPU寸士。 - 這些進程都為短時進程型奥，運行很短的時間就會結(jié)束瞳收，很難通過
top這種間隔時間較長的工具發(fā)現(xiàn)。
分析步驟和總結(jié)
??1. 通過top命令厢汹，觀察就緒隊列中的進程數(shù)量（第二行tasks中running字段的值）和下方展示的進程列表中運行態(tài)的進程數(shù)量是否存在較大的誤差。
??2. 通過pidstat命令查看可能出現(xiàn)問題的活躍進程的信息谐宙。
??3. 觀察top命令的輸出烫葬，下方的進程列表中某個進程的pid是否不斷變化。
??4. 通過pstree命令凡蜻，找出該進程的父進程搭综，然后進入app進行內(nèi)部分析，尋找不斷創(chuàng)建子進程的原因所在划栓。
??在得到猜測的結(jié)果之后兑巾，我們需要驗證該猜測到底是否正確，所以我們可以使用perf工具或者專門為短時進程設(shè)計的工具execsnoop來驗證猜想忠荞。execsnoop通過ftrace實時監(jiān)控進程的exec()行為蒋歌，并輸出短時進程的基本信息，包括進程pid委煤、父進程pid堂油、命令行參數(shù)以及執(zhí)行的結(jié)果。
系統(tǒng)中出現(xiàn)了大量的不可中斷進程和僵尸進程
??在top命令的 s(進程狀態(tài))列中包含以下幾種狀態(tài):
d: 不可中斷睡眠（uninterruptible sleep), 表示進程正在和硬件交互碧绞，不允許被其他進程打斷府框。
I: 空閑(idle)。
R: 運行(running)讥邻。
S: 可中斷睡眠（sleep）迫靖，表示進程正在等待某個事件而被系統(tǒng)掛起。當(dāng)進程等待的事件發(fā)生時兴使，它會被喚醒并進入R狀態(tài)系宜。
Z: 僵尸進程 (Zombile)，表示進程已經(jīng)結(jié)束鲫惶，但是父進程還沒有回收它的資源（比如進程描述符蜈首、PID等）
T/t: 忽略
??僵尸進程是多進程應(yīng)用容易碰到的問題。正常情況下欠母，當(dāng)一個進程創(chuàng)建了子進程后欢策，它應(yīng)該通過系統(tǒng)調(diào)用 wait() 或 waitpid() 等待子進程結(jié)束，回收子進程的資源赏淌；而在子進程結(jié)束時踩寇，會向父進程發(fā)送SIGCHLD信號，所以父進程還可以注冊SIGCHLD信號的處理函數(shù)六水，異步回收資源俺孙。
??如果父進程沒有處理子進程的狀態(tài)辣卒，子進程就提前退出，這是子進程就會變成僵尸進程睛榄。通常情況下荣茫，僵尸進程的持續(xù)時間較短，在父進程回收它的資源就會消亡场靴；或者由init進程回收后也會消亡啡莉。
??一旦父進程沒有處理子進程的終止，還一直保持運行狀態(tài)旨剥，那么子進程就會一直處于僵尸狀態(tài)咧欣。大量的僵尸進程會用盡PID進程號，導(dǎo)致不能創(chuàng)建新進程轨帜。
分析步驟和總結(jié):
??大量不可中斷進程
- 通過
top命令魄咕，觀察平均負載、進程各個狀態(tài)的數(shù)量蚌父、CPU使用率哮兰、iowait等指標(biāo)。 - 通過
dstat查看iowait升高時梢什，磁盤讀寫情況奠蹬。 - 通過
top命令觀察處于D（不可中斷）狀態(tài)的所有進程。 - 通過
pidstat命令分析進程的讀寫情況嗡午，如果該讀寫較高時囤躁，著重分析該進程的調(diào)用堆棧。
??僵尸進程
- 通過
pstree命令找出僵尸進程的父進程荔睹。 - 著重分析該進程的運行情況狸演。
