效能分析小案例系列，可以通過下面鏈結檢視哦
多程序引用很容易碰到的問題
正常情況
異常情況
重點系統配置
結果分析
狀態有 ss+、d+、r+
小s：表示這個程序是乙個會話的領導程序
+：表示前台程序組
什麼是會話和程序組
會話和程序組的場景模擬
結果分析
ps -e -o stat,ppid,pid,cmd | egrep'^[zz]'或
一提到 iowait 公升高，首先會想要查詢系統的 i/o 情況
執行 dstat 命令，觀察 cpu 和 i/o 的使用情況
找到讀磁碟的程序
不可中斷狀態代表程序在跟硬體進行互動，很可能就是讀磁碟
perf record -g15s 後 ctrl+c 終止錄製檢視報告，分析報告
並且從 new_sync_read 和 blkdev_direct_io 能看出，程序正在對磁碟進行直接讀，也就是繞過了系統快取，每個讀請求都會從磁碟直接讀，這就可以解釋觀察到的 iowait 公升高了
pstree -aps 51780通過 ps 檢視所有殭屍程序的父程序所有殭屍程序的父程序都是 51688，從而確認 51688 就是殭屍程序的父程序
有沒有呼叫 wait() 或 waitpid()
或有沒有註冊 sigchld 訊號的處理函式
把 wait() 放到了 for 死迴圈的外面，也就是說， wait() 函式實際上並沒被呼叫到，把它挪到 for 迴圈的裡面就可以了
改完原始碼，通過 top 驗證一下
殭屍程序（z 狀態）沒有了， iowait 也是 0，問題終於全部解決了
通過top檢視系統資源情況
發現平均負載逐漸公升高，iowait（wa）比較高，但使用者態和核心態 cpu 使用率並不算高
檢視是否有 cpu 使用率偏高的程序，發現有 d 狀態的程序，可能是在等待 i/o 中
過一陣子會變成 z 狀態程序，且 cpu 使用率上公升，然後會看到 zombie 程序數逐漸增加
可以得到兩個結論：殭屍程序過多，應該是父程序沒有清理已經結束的子程序的資源；iowait 的上公升導系統平均負載上公升
因為是 iowait 較高，可以通過dstat檢視系統的 i/o 情況，會發現每次 iowait 公升高，讀磁碟請求都會很大
通過pidstat -d檢視 d 狀態程序的 i/o 情況，但發現並沒有有效資訊
通過pidstat -d直接檢視系統的 i/o 情況，可以發現不斷有新程序在進行讀磁碟操作
通過ps命令檢視剛剛 d 狀態程序當前的程序狀態，發現已經變成殭屍程序
通過perf record錄製效能事件，然後通過perf report通過 pstree 找到 z 狀態程序的父程序
通過 ps 命令確認所有殭屍程序的父程序
找到父程序源**，檢查wait() / waitpid()的是否會成功呼叫，或是sigchld訊號處理函式的註冊就行了
修改完全部原始碼後，重新執行應用，通過top驗證是否還有 iowait 過高和出現 zombie 程序的情況
效能優化 CPU使用率
usr 使用者態cpu時間 nice 低優先順序使用者態cpu時間 system 系統態cpu時間 idle 空閒時間 iowait 等待io的時間 irq 硬中斷的時間 softirq 軟中斷的時間 steal 當系統執行在虛擬機器中時，被其他cpu占用的時間。gust 通過虛擬化，執行其他作業系...
Linux 系統 CPU 使用率簡單分析
cpu 使用率是單位時間內 cpu 使用情況的統計，以百分比的方式展示。為了維護 cpu 時間，linux 通過事先定義的節拍率 核心中表示為 hz 觸發時間中斷，並使用全域性變數 jiffies 記錄了開機一來的節拍數。每發生一次時間中斷，jiffies 的值就加 1。linux 通過 proc ...
效能分析（2） 應用程式 CPU 使用率過高案例
效能分析小案例系列，可以通過下面鏈結檢視哦 併發 10 個請求測試 vm1 的 nginx 效能，總共測試100個請求 從 ab 的輸出結果可以看到，nginx 能承受的每秒平均請求數只有14.73 這也太辣雞了吧 那到底是 出了問題呢 接下來，我們將通過一系列的命令來觀察 出問題了 併發 10 個...