性能監控：Linux 系統 “健康體檢” 手冊

就像人需要定期體檢一樣，Linux 服務器也需要 “健康監控”—— 當用戶反饋 “訪問變慢”“操作卡頓” 時，若能提前通過監控發現 CPU、內存、I/O 的異常，就能避免故障擴大。今天這篇 “體檢手冊”，從 “基礎實時監控” 到 “進階歷史分析”，再到 “瓶頸定位調優”，帶你掌握 Linux 性能監控的核心工具與方法，讓你成為系統的 “健康管家”。

一、基礎體檢：用 top/htop/free/vmstat 做 “實時快照”

基礎監控工具就像 “體溫計”，能快速獲取系統當前的 “健康指標”——CPU 使用率、內存占用、I/O 狀態，適合實時排查 “當下是否有問題”。

1. top/htop：實時監控 “全能工具”

top是 Linux 自帶的實時監控工具，htop是它的 “增強版”（支持鼠標操作、顏色區分），兩者核心功能一致，重點關注CPU、內存、進程三大維度。

（1）top 核心用法與指標解讀

\# 啟動top（默認每3秒刷新一次）

top

關鍵界面解讀（新手必看 5 列）：

區域 / 列名	含義	健康閾值	異常判斷標準
頂部 CPU 行	%us（用戶進程占比）、%sy（系統進程占比）、%id（空閑占比）	%id≥30%、%us≤70%、%sy≤30%	%id＜10%（CPU 繁忙）、%sy＞50%（內核占用過高）
頂部 Mem 行	total（總內存）、used（已用）、free（空閑）、buff/cache（緩存）	available（實際可用）≥總內存 10%	available＜5%（內存緊張）、buff/cache占比＞80%（緩存過多可臨時清理）
進程列 PID	進程唯一 ID	-	高 CPU / 內存進程的 PID（后續定位用）
進程列 %CPU	進程占用 CPU 百分比	單個進程≤30%（非核心服務）	非核心進程持續＞50%（可能是異常進程）
進程列 %MEM	進程占用內存百分比	單個進程≤20%（非核心服務）	非核心進程持續＞40%（可能是內存泄漏）

常用操作：

• 按P：按 CPU 占用降序排序（找 “吃 CPU” 的進程）；

• 按M：按內存占用降序排序（找 “吃內存” 的進程）；

• 按k：輸入 PID 后按回車，再輸9（強制關閉異常進程）；

• 按q：退出 top。

（2）htop 增強體驗（推薦新手使用）

htop比top更直觀，支持鼠標點擊排序、進程樹查看，安裝與使用：

\# Ubuntu安裝

sudo apt install htop -y

\# CentOS安裝

sudo dnf install htop -y

\# 啟動htop

htop

核心優勢：

• 用顏色區分 CPU 狀態（藍色：低優先級進程、綠色：用戶進程、紅色：系統進程）；

• 右側實時顯示 CPU 核心、內存、交換分區的使用率曲線；

• 鼠標點擊 “% CPU”“% MEM” 列即可排序，無需記快捷鍵。

2. free/vmstat：聚焦內存與 I/O 的 “專項檢查”

top是 “全能工具”，free和vmstat則是 “專項工具”—— 前者專注內存，后者兼顧內存與 I/O，適合深入分析資源瓶頸。

（1）free：讀懂內存 “真實可用量”

新手常被free的 “used 高、free 低” 誤導，其實關鍵看available（實際可用內存，含可回收緩存）：

\# 用-h參數（human-readable）顯示GB/MB，更直觀

free -h

輸出解讀（以 16GB 內存為例）：

                total        used        free      shared  buff/cache   available

Mem:           15Gi       6.2Gi       2.1Gi       384Mi       6.7Gi       8.3Gi

Swap:          15Gi          0B       15Gi

• 健康判斷：available=8.3Gi（占總內存 55%），Swap used=0，內存狀態健康；

• 異常信號：available＜1.5Gi（＜10%）、Swap used持續增長，需警惕內存不足。

（2）vmstat：監控內存與 I/O 的 “聯動變化”

vmstat能顯示內存交換（si/so）、磁盤 I/O（bi/bo）的實時變化，適合判斷 “是否因 I/O 拖累內存 / CPU”：

\# 每2秒輸出1次，共輸出5次（觀察趨勢）

vmstat 2 5

核心列解讀（新手重點看 4 列）：

列名	含義	健康閾值	異常判斷標準
si	從 Swap 讀入內存的大小（KB / 秒）	si≈0	持續＞100KB / 秒（內存不足，頻繁讀 Swap）
so	從內存寫入 Swap 的大小（KB / 秒）	so≈0	持續＞100KB / 秒（內存不足，被迫寫 Swap）
bi	從塊設備讀入數據（KB / 秒）	無固定閾值，看業務波動	持續＞1000KB / 秒且%util（磁盤使用率）＞80%（I/O 繁忙）
bo	寫入塊設備的數據（KB / 秒）	無固定閾值，看業務波動	持續＞1000KB / 秒且%util＞80%（I/O 繁忙）

二、進階體檢：用 sar/iostat/nmon 做 “歷史回溯與報表”

基礎工具只能看 “當下”，若要排查 “昨天下午 3 點為何卡頓”“上周內存占用峰值是多少”，就需要歷史數據分析工具——sar（系統活動報告）、iostat（I/O 統計）、nmon（報表生成），幫你回溯歷史數據、生成可視化報表。

1. sar：“全能歷史記錄者”（CPU / 內存 / I/O 全記錄）

sar是 Linux 性能監控的 “瑞士軍刀”，能周期性采集系統活動數據，支持事后回溯，默認安裝在大部分系統中。

（1）核心用法：采集與查看歷史數據

\# 1. 實時采集（每5秒采集1次，共采集10次，輸出到終端）

sar 5 10

\# 2. 采集并保存數據（每5秒采集1次，共10次，保存到sar.log）

sar 5 10 -o sar.log

\# 3. 查看歷史數據（從sar.log中查看CPU使用情況）

sar -f sar.log -u  # -u：查看CPU相關數據

（2）常用場景與參數組合

監控目標	命令	關鍵指標解讀
CPU 歷史占用	sar -f sar.log -u	%idle（空閑占比）：若某時段＜10%，說明當時 CPU 繁忙
內存歷史占用	sar -f sar.log -r	%memused（內存使用率）：持續＞90% 需警惕內存不足
磁盤 I/O 歷史	sar -f sar.log -b	tps（每秒 I/O 次數）、rtps（每秒讀次數）：異常高峰對應 I/O 繁忙時段
網絡流量歷史	sar -f sar.log -n DEV	rxpck/s（每秒接收包數）、txpck/s（每秒發送包數）：異常增長可能是網絡攻擊

（3）實戰：回溯 “昨天下午 3 點的 CPU 異常”

\# 1. 查看系統默認保存的sar歷史數據（CentOS默認存于/var/log/sa/，Ubuntu需手動配置）

ls /var/log/sa/  # 輸出如sa25（25日的數據）

\# 2. 查看25日15:00-15:30的CPU數據（-s指定開始時間，-e指定結束時間）

sar -f /var/log/sa/sa25 -u -s 15:00:00 -e 15:30:00

\# 3. 解讀結果：若15:10-15:15的%idle＜5%，說明當時CPU繁忙，再結合top歷史進程排查

2. iostat：I/O 性能的 “專項分析師”

sar是 “全能工具”，iostat則專注于磁盤 I/O 監控，能精準定位 “哪個磁盤最繁忙”“哪個進程在頻繁讀寫”，適合排查 “I/O 瓶頸導致的卡頓”。

（1）基礎用法：查看磁盤 I/O 狀態

\# 安裝iostat（屬于sysstat包）

sudo apt install sysstat -y  # Ubuntu

sudo dnf install sysstat -y  # CentOS

\# 查看所有磁盤的I/O統計（-x：顯示詳細指標，-k：以KB為單位）

iostat -x -k

（2）關鍵指標解讀（判斷磁盤是否繁忙）

指標名	含義	健康閾值	異常判斷標準
%util	磁盤繁忙百分比（I/O 時間占比）	≤60%	持續＞80%（磁盤 I/O 飽和，是卡頓主因）
rMB/s	每秒讀數據量（MB）	無固定閾值，看磁盤性能	遠超磁盤標稱讀寫速度（如機械盤＞100MB/s）
wMB/s	每秒寫數據量（MB）	無固定閾值，看磁盤性能	遠超磁盤標稱讀寫速度
avgqu-sz	平均 I/O 隊列長度	≤2	持續＞5（I/O 請求排隊過多，磁盤處理不過來）

（3）進階：定位 “繁忙磁盤對應的進程”

當iostat發現/dev/sdb的%util=95%（I/O 飽和），用iotop找對應的讀寫進程：

\# 安裝iotop

sudo apt install iotop -y  # Ubuntu

sudo dnf install iotop -y  # CentOS

\# 啟動iotop（按P顯示進程PID，按O只顯示有I/O活動的進程）

sudo iotop -P -O

輸出中 “DISK READ”“DISK WRITE” 列數值高的進程，就是導致磁盤繁忙的 “元兇”（如PID=1234的mysql進程頻繁寫數據）。

3. nmon：性能報表的 “自動生成器”

對于需要輸出 “監控報表” 的場景（如給領導匯報、故障復盤），nmon是最佳選擇 —— 它能實時監控 CPU、內存、I/O、網絡，還能生成 CSV 格式報表，方便后續用 Excel 或 Python 分析。

（1）安裝與啟動 nmon

\# Ubuntu安裝

sudo apt install nmon -y

\# CentOS安裝

sudo dnf install nmon -y

\# 啟動nmon（默認顯示系統概覽）

nmon

（2）核心操作：查看不同資源與生成報表

需求	操作	說明
查看 CPU 詳情	按c鍵	顯示各 CPU 核心的使用率、等待時間等
查看內存詳情	按m鍵	顯示內存使用、Swap 使用、緩存情況
查看磁盤 I/O 詳情	按d鍵	顯示各磁盤的讀寫速度、繁忙百分比
查看網絡詳情	按n鍵	顯示各網卡的接收、發送流量
生成 CSV 報表	啟動時加-f -s 5 -c 720參數	nmon -f -s 5 -c 720：每 5 秒采集 1 次，共 720 次（1 小時），生成 nmon_日期_時間.csv 文件

（3）報表分析：用 Excel 可視化

1. 找到生成的 CSV 文件（如nmon_20241025_1400.csv）；

2. 用 Excel 打開，按 “數據→分列→逗號分隔” 拆分數據；

3. 選中 CPU 使用率、內存使用率列，插入 “折線圖”，即可直觀看到 1 小時內的性能趨勢（如 14:30-14:40 CPU 使用率驟升）。

三、調優實戰：CPU / 內存 / I/O 瓶頸定位與解決

監控的最終目的是 “解決問題”—— 當發現 CPU、內存、I/O 異常時，需結合進程、內存、網絡管理知識，定位瓶頸根源并優化。

1. 瓶頸 1：CPU 使用率 100%（系統卡頓、響應慢）

定位步驟：

1. 找高 CPU 進程：用top按P排序，找到%CPU持續＞80% 的進程（如PID=4567的java進程）；

2. 看進程是否異常：用ps aux | grep 4567查看進程命令（如java -jar app.jar，是業務應用還是異常腳本）；

3. 查線程級占用：若進程是多線程（如 Java、Nginx），用pidstat -t -p 4567 2 3查看線程占用，定位到具體繁忙線程（%CPU高的線程 ID）；

4. 分析線程用途：Java 進程可結合jstack 4567查看線程棧，判斷是否有死循環、頻繁 GC（垃圾回收）。

解決方法：

• 若為異常進程（如病毒、測試腳本）：sudo kill -9 4567強制關閉；

• 若為業務進程（如 Java 應用）：

  • 臨時：重啟進程（sudo systemctl restart app）緩解；

  • 長期：優化代碼（如修復死循環、減少 CPU 密集型操作）、升級 CPU 或增加核心數。

2. 瓶頸 2：內存泄漏（內存占用持續增長、Swap 頻繁使用）

定位步驟：

1. 確認內存趨勢：用sar -f sar.log -r查看內存使用率，若%memused從 50% 持續漲到 90%，且無下降，懷疑內存泄漏；

2. 找泄漏進程：用top按M排序，找到%MEM持續增長的進程（如PID=7890的python腳本）；

3. 驗證泄漏：用ps aux --sort=-%mem | grep 7890觀察進程內存變化，1 小時后VSZ（虛擬內存）、RSS（物理內存）明顯增長，確認泄漏。

解決方法：

• 臨時：重啟泄漏進程（sudo kill -15 7890，正常關閉避免數據丟失）；

• 長期：排查代碼（如 Python 腳本未釋放數據庫連接、Java 靜態集合未清理），或用valgrind（C/C++）、jmap+jhat（Java）分析內存泄漏點。

3. 瓶頸 3：磁盤 I/O 飽和（%util＞90%、讀寫卡頓）

定位步驟：

1. 找繁忙磁盤：用iostat -x -k找到%util高的磁盤（如/dev/sdc）；

2. 找對應進程：用iotop -P -O找到讀寫該磁盤的進程（如PID=3456的rsync備份進程）；

3. 分析 I/O 類型：用sar -f sar.log -b查看是 “讀多” 還是 “寫多”（rtps高是讀瓶頸，wtps高是寫瓶頸）。

解決方法：

• 若為臨時任務（如rsync備份）：調整任務時間（避開業務高峰）；

• 若為業務進程（如 MySQL）：

  • 優化存儲：將機械盤換成 SSD（提升讀寫速度 10 倍以上）；

  • 優化 I/O 操作：MySQL 開啟緩存（innodb_buffer_pool_size調大）、減少頻繁小文件讀寫（合并成大文件）；

  • 分散 I/O：將數據分散到多塊磁盤（如用 LVM 或 RAID 10）。

四、避坑指南：3 個監控常見誤區

1. 誤區 1：只看單一指標，忽略聯動分析

表現：看到 CPU 使用率 100%，直接殺死高 CPU 進程，卻沒發現是磁盤 I/O 飽和導致 CPU 等待（%wa高）。

正確做法：CPU 異常時，結合vmstat看%wa（I/O 等待時間占比），若%wa＞20%，先解決 I/O 瓶頸（如優化磁盤讀寫），再看 CPU 是否恢復。

2. 誤區 2：過度依賴實時監控，不存歷史數據

表現：故障發生后，才發現沒保存歷史數據，無法回溯 “故障前的指標變化”。

正確做法：配置sar自動采集歷史數據（CentOS 默認開啟，Ubuntu 需編輯/etc/cron.d/sysstat，設置5-59/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1，每 10 分鐘采集 1 次）。

3. 誤區 3：用 “默認閾值” 判斷所有系統

表現：認為 “CPU% idle＜10% 就是異常”，但數據庫服務器正常業務下%idle常＜5%。

正確做法：結合 “業務場景” 定閾值 —— 數據庫服務器 CPU 繁忙是常態，重點看%wa（I/O 等待）；Web 服務器則需%idle≥30%，避免用戶訪問卡頓。

總結：Linux “健康體檢” 核心流程

1. 日常巡檢：用htop看實時狀態，用nmon生成日報表，重點關注 CPU% idle、內存 available、磁盤 % util；

2. 故障排查：

• 卡頓先看top（找高 CPU / 內存進程）；

• 慢響應查iostat（看 I/O 是否飽和）；

• 歷史問題用sar回溯（定位故障時段指標）；

1. 瓶頸調優：CPU 看線程、內存查泄漏、I/O 找磁盤，結合業務場景優化（臨時重啟 vs 長期代碼 / 硬件優化）。

掌握這套 “體檢手冊”，你就能從 “被動救火” 變成 “主動預防”，讓 Linux 服務器始終保持 “健康狀態”，減少因性能問題導致的業務中斷。