linux 性能自我學習 ———— cpu 快速定位問題 [六]
前言
主要介紹一下cpu如何快速定位問題。
正文
cpu 的一些性能指標：
1. cpu 使用率
cpu 使用率描述了非空閑時間占總cpu時間的百分比，根據cpu上運行任務的不同，又被分為用戶cpu、系統cpu、 i/o 等待cpu、 軟中斷、硬中斷。
用戶cpu使用率，包括用戶態cpu使用率，和低優先級用戶態cpu 使用率，表示cpu 在用戶態運行的時間的百分比。
用戶cpu 使用率搞，通常說明應用程序比較繁忙。
-
系統cpu使用率，表示cpu在內核態運行的時間百分比（不包括中斷）。系統cpu使用率高，說明內核比較繁忙。
-
等待i/o 的cpu使用率，通常也稱為iowait，表示等待i/o 的時間百分比。 io wait高，說說嗎系統與硬件設備的i/o交互時間比較長。
-
軟中斷和硬中斷的cpu使用率，分布表示內核調用軟中斷處理程序、硬中斷處理程序的時間百分比。它們的使用率搞，通常說明系統發送了大量的中斷。
2. 平均負載
也就是系統的平均活躍進程數，它反應了系統的整體負債情況，主要包括三個數值，分別指過去1分鐘、過去5分鐘、過去15分鐘的平均負載。
理想情況下，平均負載等于邏輯cpu個數，它表示cpu恰好被充分利用，一般可以大于70%。
3. 進程上下文切換
-
無法獲取資源導致的資源上下文切換
-
被系統強制調度導致的非自愿上下文切換
上下文切換，本身保證了linux 正常運行的一項核心功能。但過多的上下文切換，會將原本運行進程的cpu時間，消耗在寄存器、內核棧、以及虛擬內存等數據的保存和恢復上，
縮短進程真正運行的時間，稱為性能瓶頸。
用什么工具來排查呢？
幾個案例總結:
- 平均負載案例。
先用uptime，查看系統的平均負載；而在平均負載升高后，又用mpstat和pidstat，分布觀察了每個cpu 和 每個進程cpu的使用情況，進而找出導致平均負載高的進程，使用的是stress 工具。
- 上下文切換的案例
先用vmstat 查看系統上下文切換和中斷次數。
然后通過pidstat，觀察和進程的自愿上下文切換和非自愿上下文切換情況。最后通過pidstat，觀察線程的上下文切換情況，找出上下文切換次數增多的根源，也就是我們的基準測試工具sysbench。
-
進程cpu 升高案例，先用top，然后是perf top。
-
短時進程問題，系統cpu搞，但是找不到進程。 可能是短時進程，崩潰等。
通過perf record 和 perf report。
短時進程可以使用execsnoop。
- 不可中斷進程或者僵尸進程的案例。 我們先用top 觀察到了iowait升高的問題，并發現了大量的不可中斷進程和僵尸進程；
接著我們用dstat 發現是磁盤導致的，于實通過pidstat 找到了相關的進程。 可以用strace查看進程系統調用失了，最后通過perf分析進程調用鏈，發現磁盤i/o問題。
- 軟中斷案例，通過top 觀察到，系統的軟中斷cpu 使用高。
通過top查看系統的軟中斷cpu使用率升高；接著查看/proc/softirqs 找到了幾種變化快的軟中斷，通過sar命令，發現網絡小包的問題。
最后用tcpdump 找出網絡幀的類型和來源，確定是一個syn flood 攻擊導致的。
工具表:
示例圖:
結
下一節，內存相關。