# Linux 效能監控實戰教學：用 htop、iostat、vmstat 揪出系統瓶頸
做 IT 嘅你一定試過呢個場景：Server 突然慢到嘔，CPU 飆到 100%，但係你完全唔知邊個 process 搞鬼。今日就同大家分享幾招 Linux 效能監控嘅實戰技巧，等你可以 5 分鐘內鎖定問題根源。
## 第一步：htop — 一眼睇晒全系統狀態
`top` 係經典，但 `htop` 先係真正好用嘅工具。彩色介面、滑鼠支援、直覺式操作，一裝就愛上。
# 安裝 htop
sudo apt install htop -y # Debian/Ubuntu
sudo yum install htop -y # RHEL/CentOS
# 直接執行
htop入到 htop 之後，撳 `F6` 可以揀排序方式 — 通常我會揀 `PERCENT_CPU` 或者 `PERCENT_MEM`，即刻睇到邊個 process 最食資源。撳 `F9` 可以直接 kill process，撳 `F5` 睇 tree view 睇 parent-child 關係。
**實戰技巧：** 如果你見到 `mysqld` 或者 `java` 長期霸住 CPU top 1，唔好即刻 kill — 先用 `F2` 入 setup，加多幾個 column 睇 `IO_RATE` 同 `IO_READ_RATE`，確認係 CPU bound 定 I/O bound 先決定下一步。
## 第二步：vmstat — 虛擬記憶體全面體檢
`vmstat` 係睇系統整體健康狀況嘅神器，特別係 memory、swap、I/O 呢三個維度。
# 每 2 秒更新一次，連續顯示 10 次
vmstat 2 10輸出重點睇呢幾欄：
– **si / so**：swap in / swap out。如果 so 持續 > 0，代表 RAM 唔夠用，系統被迫將 memory page 寫入 disk — 呢個係效能殺手！
– **bi / bo**：block in / out。數值突然飆升代表 disk I/O 瓶頸。
– **wa**：CPU wait for I/O。如果 wa > 10，代表 CPU 成日等 disk，你嘅 storage 係 bottleneck。
– **r**：run queue。如果 r > CPU core 數，代表太多 process 排隊等 CPU。
**實戰案例：** 有一次我見到 `wa` 長期 25-30%，`bi` 每秒幾萬 — 原來係 backup script 喺 peak hour 行緊 `rsync`。搬咗個 cron job 去凌晨 3 點，問題即刻解決。
## 第三步：iostat — Disk I/O 深度分析
當 `vmstat` 話你知 disk 有問題，就要出動 `iostat` 做深入診斷。
# 安裝 sysstat 套件（包含 iostat）
sudo apt install sysstat -y
# 每 1 秒更新，顯示 extended 資訊
iostat -x 1 5關鍵指標：
– **%util**：device 忙碌百分比。如果接近 100%，代表 disk 已經 full load。
– **await**：平均 I/O 等待時間（ms）。如果 > 20ms 代表 disk 反應慢，SSD 正常應該 < 5ms。
- **r_await / w_await**：分別睇 read 同 write latency，幫你判斷係讀定寫出事。
- **avgqu-sz**：平均 queue 長度。如果長期 > 1，代表 I/O request 堆積。
**實戰技巧：** 如果你用緊 cloud VM（AWS EC2 / Azure VM），`iostat` 可以幫你確認係咪 hit 到 IOPS limit。好多 cloud provider 對細 instance 有 IOPS throttling，`%util` 100% 但 throughput 唔高就係中招。
## 第四步：dstat — 全能監控瑞士軍刀
`dstat` 係一個 all-in-one 工具，將 cpu、disk、net、memory、system 全部整合喺一個畫面。
# 安裝 dstat
sudo apt install dstat -y
# 全功能監控
dstat -cdnmgy --top-cpu --top-mem --top-io 2呢個 command 會同時顯示：CPU usage、disk read/write、network send/recv、memory usage、page in/out、system interrupt/context switch，再加 top CPU、top memory、top I/O process。一個 terminal window 睇晒全系統！
## 第五步：sar — 歷史數據回溯分析
以上工具都係 real-time，但如果問題係凌晨 3 點發生而你瞓緊覺，就要靠 `sar` 嘅歷史記錄功能。
# 啟用 sar 數據收集（預設每 10 分鐘記錄一次）
sudo systemctl enable sysstat
sudo systemctl start sysstat
# 睇返今日 CPU 歷史
sar -u | tail -20
# 睇返尋日 memory 歷史
sar -r -f /var/log/sysstat/sa$(date -d yesterday +%d)
# 睇 network 歷史
sar -n DEV | grep eth0`/var/log/sysstat/` 下面會保存每日嘅 binary log，`sar` 可以讀返任何一日嘅數據。呢個功能對於 troubleshooting 間歇性問題極之有用 — 唔使通宵等住個 terminal！
## 實戰整合：5 分鐘排查流程
當你收到「server 好慢」嘅 alert，跟住呢個流程：
1. **`htop`** → 睇 CPU/RAM top consumer（30 秒）
2. **`vmstat 2 5`** → 確認係 CPU/RAM/Disk 邊個 bottleneck（10 秒）
3. **`iostat -x 1 5`** → 如果係 disk，深入睇 latency 同 IOPS（5 秒）
4. **`dstat -cdnmgy 2`** → 全系統 cross-reference（30 秒）
5. **`sar`** → 如果問題已過，回溯歷史搵 root cause（1 分鐘）
成個流程 5 分鐘內完成，由茫無頭緒到鎖定瓶頸。記住：**唔好憑感覺亂 kill process，用數據說話！**
## 進階 Tips
– **htop** 可以 save setup config，下次開自動 load 你嘅 custom layout
– **vmstat** 第一個 row 係 since boot 嘅 average，通常 ignore 佢，睇之後嘅 real-time sample
– **iostat** 對 NVMe SSD 嘅 `%util` 可能唔準（因為 NVMe 有 parallel queue），要睇 `await` 為主
– 將 `sar` log 射去 centralized monitoring（ELK / Grafana）可以做長期 trend analysis
🔗 參考資料：NVD NIST 漏洞資料庫
希望呢篇教學幫到大家！下次 server 出事，唔使驚，跟住流程一步步嚟就得。有咩問題歡迎留言討論～
#Linux #技術分享 #IT教學 #backup #監控
