Linux應用性能分析及故障排查

本文核心內容：

• Linux性能分析
• 故障模擬和混沌工廠
• 故障分析和解決

一、Linux性能分析

上圖、性能優化命令速查，圖片較大，建議下載回本地

1.1 什麼是Linux性能問題

• CPU使用率過高 00%！！！
• CPU負載過高
• 內存溢出
• 磁盤空間不夠
• 網絡寬帶被打滿

是系統資源不夠？還是程序寫的有問題？

1.2 Linux下四大性能指標

• 內存
• CPU
• 磁盤
• 帶寬

1.3 CPU性能指標

CPU使用率：CPU的使用率
平均負載：單位時間內的活躍線程數
用戶時間：CPU在用戶進程上的實際百分比
系統時間：CPU在內核上花費的實際百分比
空閒時間：系統處於在等待IO操作上的時間總和
等待：CPU花費在等待IO操作上的時間總和
Nice時間：CPU優先執行的時間百分比

CPU使用率和CPU負載

CPU使用率是單位時間內CPU繁忙情況的統計，跟平均負載並不一定完全對應
平均負載是單位時間內的活躍進程數（處於可運行狀態和不可中斷狀態的進程，也就是有沒有獲取到時間片）

這裏舉個形象的例子：
比如我們去坐電梯，電梯一次只能坐10個人，假設現在電梯內有10個人那麼負載就是剛好的*1，一部電梯就是一核CPU，10個人剛剛好，但是超過10個人，其他人就得等待，10個人先上去，剩下的人就得等待，這時候就涉及到了CPU的等待情況，CPU已經繁忙了，本來10個人CPU的繁忙是1，那麼20人、30人，那麼CPU的負載就是2倍、3倍、甚至是4倍，CPU的使用率就是，每一層有多少人下去，假設電梯裏的10個人都是去同一層，那麼這個使用率就是非常高的

使用top命令，我們可以查詢到CPU的使用率，等待，平均負載的一些情況

注意：CPU負載和CPU使用率沒有直接關係！！！

CPU負載和使用率的關係

• CPU密集型進程，使用大量的CPU會導致平均負載升高，此時這兩者是一致的

• I/O密集型進程，等待I/IO也會導致平均負載升高，但CPU使用率不一定很高

• 大量等待CPU的進程調度也會導致平均負載升高，此時的CPU使用率也會比較高

所以我們可以知道，辨別一個程序是不是耗費CPU，就要看它是CPU密集型還是I/O密集型，CPU密集型就是程序執行大量的計算，這個時候CPU的使用率會非常高、而I/O密集型就是程序會讀取大量的I/O，比如網絡間傳輸大文件，或者是Mysql全表掃描的情況，這個CPU負載非常高，但是CPU使用率很低，因爲這個時候一直在等待I/O。

注意：CPU負載和CPU使用率沒有直接關係！！！

CPU上下文切換

• CPU寄存器是CPU內置的容量小，但速度極快的內存。

• 程序計數器用來存儲CPU正在執行的指令位置，即將執行的下一條指令位置，這些都是CPU執行任務前，要依賴的環境，也叫做CPU上下文。

• 上下文切換，就是先把前一個任務的CPU上下文，保存起來，然後加載新任務的上下文到寄存器和計數器中，纔開始運行新任務

上下文切換的次數

儘量減少CPU的上下文切換！！！
上下文切換的幾類：

• 進程上下文切換
• 線程上下文切換
• 中斷上下文切換

進程上下文切換
舉例：
假設我們程序先執行的thread1 —> 下個時間片輪到thread2，那麼就是進程1 —> 進程2，這也就是進程之間的切換

線程上下文切換
舉例：
thread1 —> thread3，這個時候進程內共享的上下文信息，不需要去加載，但是呢，需要切換每個線程棧的信息，這個時候就是線程的上下切換

中斷上下文切換
這裏涉及到內核的中斷，就是CPU暫停正在執行的程序，保存狀態，也就是中斷它，然後在CPU處理完後會回到斷點繼續執行，跟進程上下文切換一樣，中斷上下文切換也需要消耗CPU

如何分析上下文切換

執行vmstat命令，查看系統整體情況
cs（context switch）是每秒上下文切換的次數
in（interrupt）是每秒中斷的次數
r （Running or Runnable）是就緒隊列的長度，也就是正在運行和等待CPU的進程數
b（Blocked）則是處於不可中斷睡眠狀態的進程數

vmstat 5
注：5這個參數是指我們多長時間再去採樣刷新一次信息

CPU負載高、使用率低？

產生原因
等待磁盤I/O完成的進程過多，導致進程隊列長度過大，但是cpu運行的進程卻很少，這樣就體現到負載過大了，cpu使用率低

常見場景
磁盤讀寫請求過多導致大量IO等待Mysql死鎖、Mysql全表掃描

什麼樣的指標纔是合理的使用CPU

CPU使用率高、負載同時也高，是完全的CPU使用
像我們常說的高性能不只是說我們的qps上去了，而是要我們單機的CPU使用率達到了最優，這個時候纔是高性能、否則就是浪費機器，用機器堆出來的高性能。

負載最優業界兩種指標：

• 1. CPU負載小於核數*0.7
• 2. CPU負載小於核數-1

如何分析CPU

• 1. 查看CPU核數
• 2. 查CPU負載和CPU使用率
• 3. 查看進程CPU使用情況
• 4. 查看線程上下文切換情況
• 5. 查看線程的CPU使用情況

注：這裏感興趣的可以自行去了解查詢資料

1.4 內存性能指標

空閒內存
Swap使用率
緩衝和緩存
Slabs描述的內核使用量
活動和非活動內存

free -m

理解Cached

cached通常屬於available部分（該數據3.14內核之後提供，procps-ng較新版本也顯示）,也就是可用內存。什麼時候程序需要了，什麼時候拿去用。

理解Swap

簡單來講，就是用硬盤的一塊空間來當做內存使用。

內存不足時，會使用Swap，把進程暫時不用的數據存儲到磁盤中

Swap會導致嚴重的性能問題

理解Cached過大是怎麼回事？

使用Nginx、Netty時Cached用量過大，爲什麼？

這些都是高性能的網絡I/O程序，並且還要記日誌的，這個時候網絡I/O和磁盤I/O都是需要做臨時存儲，做緩存的

清空cached，cached是系統爲了提升I/O性能給你緩存下來的，是可以清空的！
清空cached是不會影響系統數據的！

echo 1 > /proc/sys/vm/drop_caches

1.5 IO性能指標

• 磁盤使用率
• IO飽和度
• IOPS
• 吞吐量
• 響應時間

順序讀寫和隨機讀寫

順序讀寫和隨機讀寫，我們一般稱爲順序IO、隨機IO。
順序IO： 可以通過預讀來將一部分數據提前加載到內存中
隨機IO： 需要多次尋址

舉例:爲什麼Kafka性能高，順序寫（追加寫）它是連續的

標準IO、直接IO、MMAP

**標準IO：**緩存IO、系統默認IO
**直接IO：**直接讀取硬盤（直接IO+異步IO）
mmap： 內存映射

頁緩存

持久化應該怎麼做？

• 方法一：來一行，持久化一行。
• 方法二：來一行，內存中記錄下來，累計一批，刷盤持久化！

Kafka —>寫入頁緩存—>磁盤

線上磁盤最常出的問題

磁盤可用空間不足，怎麼辦？
首頁想到的是什麼？清理日誌！！！
如果清理了日誌，還是不行，那麼就尋址存在的大文件

du -h --max-depth=1

什麼地方容易出現IO問題？

• 中間件
• 消息隊列Kafka
• 搜索引擎ElasticSearch
• 數據庫Mysql

應用
大批量日誌打印（同步打印，異步打印）

iostat

更多我們可以查看第一張圖的速查表！！！

好用的磁盤IO性能排查工具

**iostat：**查看塊設備維度的磁盤IO情況
**pidstat：**查看進程級別的資源情況
**iotop：**查看磁盤整體情況和各進程情況

先通過iostat查看整體的磁盤IO情況
在結合iotop和pidstat分析具體的進程情況

1.6 網絡性能指標

**寬帶：**百兆、千兆
吞吐量：
**延遲：**網絡發起 - 收到響應的耗時
**PPS：**Package Per Second，每秒傳輸的包數
**網絡可用性：**網絡通不通
併發連接數：
**丟包率：**網絡故障、發生n次，失敗m次

網絡可用性

網絡通不通，先來ping一ping

ping不通（先排除不讓ping的情況），原因排查，測試網絡路由情況，斷在那裏？
traceroute，網絡路由情況，一覽無遺！！！

DNS查詢

nslookup www.baidu.com

網卡配置查看

要查看網絡配置，通過ipconfig | ip addr查看網卡信息和網絡新。

二、故障模擬和混沌工廠

2.1 模擬故障工具

Sysbench：https://github.com/akopytov/sysbench

模擬20個線程，壓測3分鐘

sysbench --threads=20 --time=180 threads run

然後我們通過top和vmstat查看

top

vmstat 2

新時代的故障注入工具——混沌工程

混沌工程是一門新興的技術學科，他的初衷是通過實驗性的方法，讓人們建立對於複雜分佈式系統在生產中抵禦突發事件能力的信心。 - -混沌工程原則

故障演練

ChaosBlade

ChaosBlade 是一款遵循混沌工程實驗原理，建立在阿里巴巴近十年故障測試和演練實踐基礎上，並結合了集團各業務的最佳創意和實踐，提供豐富故障場景實現，幫助分佈式系統提升容錯性和可恢復性的混沌工程工具。

https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md

參考文章：
https://blog.csdn.net/u013256816/article/details/99917021

https://www.cnblogs.com/pigpdong/p/10932415.html

三、故障分析和解決

3.1 分析CPU問題

1. top命令分析上下文切換
2. vmstat分析上下文切換
3. pidstat分析上下文切換和CPU使用情況
4. 通過ps獲取進程ID
5. strace跟蹤進程情況

這裏就不截圖了，文章的核心是提供思路，而這些命令相信大家都基本瞭解過，如果有不瞭解的，可以查閱一下資料

3.2 優化CPU問題

1. 程序減少不必要的工作
2. 程序減少循環層次、減少遞歸
3. 優化算法
4. 異步處理，防止阻塞
5. 善用緩存，防止IO等待
6. CPU綁定（nginx綁定CPU）
7. 限制CPU資源（cgroup，docker）

3.3 監控

CPU需要監控
內存需要監控
磁盤空間需要監控
…
監控之後，程序還要告警，通知我們處理問題！！！