【Linux】 進程管理進階：從 ps 到 pidstat，高手都在用的監控技巧

• 摘要
• 目錄

• 1\. 引言：為什麼需要進階的進程管理？

• 1.1. 基礎工具的侷限性
• 1.2. 進階監控的目標

• 2\. `ps` 命令的精進使用

• 2.1. 組合選項與精確篩選
• 2.2. 自定義輸出格式 (`-o` 選項)
• 2.3. 線程級別監控 (`-L` 或 `H` 選項)

• 3\. 交互式監控工具：`htop` 的優勢

• 3.1. 安裝與界面佈局
• 3.2. 進程樹與信號發送

• 4\. 進程資源分析的終極利器：`pidstat`

• 4.1. `sysstat` 工具包的安裝
• 4.2. CPU 使用率的精細化監控
• 4.3. 內存與頁錯誤監控 (`-r`)
• 4.4. 深入 I/O 行為分析 (`-d`)
• 4.5. 任務切換與上下文切換分析 (`-w`)

• 5\. 實戰案例：定位高 I/O 進程

• 5.1. 傳統 `top` 的盲區
• 5.2. `pidstat -d` 的精準定位

• 6\. 總結與展望
• 相關鏈接

摘要

在 Linux 系統維護和性能調優中，對系統進程的精確監控和管理是核心技能。本文旨在將讀者的進程管理知識從基礎的 ps、top 命令提升到更專業的層面。我們將深入探討 ps 命令的強大篩選和格式化能力，掌握 htop 的交互式優勢，並重點介紹由 sysstat 包提供的**pidstat**工具。pidstat 提供了遠超傳統工具的精細化、歷史性進程資源使用數據（如 CPU、內存、I/O），是排查複雜性能問題的利器。通過本文的學習，您將掌握一套完整的 Linux 進程監控和診斷進階技巧。

關鍵詞： Linux、進程管理、性能監控、ps、top、htop、pidstat、sysstat、I/O 監控

目錄

1. 引言：為什麼需要進階的進程管理？

1.1. 基礎工具的侷限性

大多數 Linux 用户對 ps aux 和 top 命令耳熟能詳。然而，在處理生產環境中的複雜性能問題時，這些工具往往顯得力不從心：

1. ps： 只能提供進程狀態的瞬間快照，無法提供歷史趨勢。
2. top： 雖可動態刷新，但其 I/O 統計、內存使用（尤其在有大量緩存時）的展示不夠直觀和精確，且默認粒度是進程，難以分析到線程級別。
3. 缺乏 I/O 細粒度分析： 傳統的工具難以直接清晰地展示哪個進程是 I/O 瓶頸的元兇。

1.2. 進階監控的目標

進階的進程管理旨在實現以下目標：

1. 精確性： 獲得進程在特定時間段內 CPU、內存、I/O 等指標的準確數值。
2. 細粒度： 能夠下探到線程級別的資源使用情況，以便精確診斷多線程應用的問題。
3. 歷史性： 能夠監控並記錄一段時間內的性能數據，以便進行趨勢分析和事後追溯。

2. ps 命令的精進使用

儘管 ps 是一個基礎工具，但其強大的選項組合使得它在自動化腳本和一次性查詢中仍是不可替代的。

2.1. 組合選項與精確篩選

最常用的 ps 組合是 aux 和 ef。進階使用則側重於篩選特定用户、終端或狀態的進程。

# 示例1: 查找特定用户 (user) 下的 Java 進程
# -u：按用户名篩選
# -f：完整格式輸出
ps -fu user | grep java

# 示例2: 查找所有處於“殭屍 (Z)”狀態的進程
# -A：選擇所有進程
# -eo：自定義輸出格式
ps -A -eo pid,ppid,user,stat,cmd | grep -w Z

# 示例3: 查找TTY為tty1的所有進程
# -t：按終端篩選
ps -ft tty1

解釋： 通過 -u、-t 等選項，我們可以快速鎖定目標進程集。尤其需要注意的是殭屍進程 (Z 狀態)，它通常是父進程編程錯誤未及時 wait() 子進程導致的。

2.2. 自定義輸出格式 (-o 選項)

ps 的 -o 選項允許用户定義輸出的列，這對於編寫腳本或只關注特定指標時非常有用。常用的字段包括 pid (進程ID), vsz (虛擬內存大小), rss (常駐內存大小), pcpu (CPU佔用百分比) 等。

# 示例: 只輸出進程ID、常駐內存大小 (RSS) 和進程命令
ps -eo pid,rss,cmd --sort=-rss | head -n 10

解釋： --sort=-rss 表示按常駐內存使用量降序排列，head -n 10 則只顯示前十個，迅速定位內存消耗大户。

2.3. 線程級別監控 (-L 或 H 選項)

在診斷多線程應用（如 Web 服務器、數據庫）時，僅監控進程級別 CPU 意義不大。我們需要查看哪個線程消耗了最多的 CPU。

# 示例: 顯示特定進程 (PID 12345) 的所有線程
# -L：顯示 LWP (輕量級進程，即線程ID) 和 NLWP (線程數)
# -o：自定義輸出，顯示 LWP 和線程狀態
ps -Lp 12345 -o pid,lwp,nlwp,pcpu,stat,cmd

# 替代用法: 顯示所有進程的線程，並按 CPU 排序
# H：樹狀顯示進程/線程
ps -eLf --sort=-pcpu | head -n 20

解釋： LWP (Light Weight Process) 就是線程 ID。通過監控 LWP 的 CPU 佔用，可以精確發現應用內部的性能瓶頸線程。

3. 交互式監控工具：htop 的優勢

htop 是 top 的增強版，提供了友好的交互式界面和更多功能，是日常監控的首選。

3.1. 安裝與界面佈局

如果系統未安裝，可以通過包管理器安裝：

# Debian/Ubuntu
sudo apt update && sudo apt install htop

# RedHat/CentOS/Fedora
sudo yum install epel-release && sudo yum install htop

htop 的主要優勢在於其界面佈局：

• 頂部： 清晰地顯示 CPU、內存和 Swap 的使用條。
• 中部： 進程/線程列表，默認支持顏色高亮和垂直滾動。
• 底部： 功能鍵提示 (F1-F10)，方便用户進行排序、篩選、樹狀顯示等操作。

3.2. 進程樹與信號發送

1. F5 (Tree View): 切換到進程樹視圖。這對於理解進程間的父子關係、識別哪個父進程啓動了大量子進程（如 Web 服務器）非常有幫助。
2. F4 (Filter): 快速輸入字符串過濾進程列表。
3. F9 (Kill): 方便地向選定的進程發送信號（如 SIGTERM、SIGKILL），無需記憶進程 ID。

4. 進程資源分析的終極利器：pidstat

pidstat 是 sysstat (System Performance Tools for Linux) 工具包的一部分，它專門提供進程級別的歷史性和細粒度資源使用統計，是排查高負載問題的核心工具。

4.1. sysstat 工具包的安裝

# Debian/Ubuntu
sudo apt install sysstat

# RedHat/CentOS/Fedora
sudo yum install sysstat

4.2. CPU 使用率的精細化監控

pidstat 的基本語法是：pidstat [選項] [間隔秒數] [次數]。

# 示例: 每隔 2 秒鐘採樣 5 次，監控所有進程的 CPU 使用情況
pidstat 2 5

# 關鍵輸出列説明：
# %user：用户空間 CPU 佔用百分比
# %system：內核空間 CPU 佔用百分比
# %guest：虛擬機 CPU 佔用百分比
# %CPU：總 CPU 佔用百分比
# Command：進程名稱

# 示例: 僅監控 PID 為 12345 的進程，並顯示線程統計 (-t)
pidstat -t -p 12345 5 1

解釋： pidstat 的強大之處在於它能提供一個時間序列的平均值，而不是像 ps 那樣的瞬間快照。通過 -t 選項，我們可以將統計粒度精確到線程。

4.3. 內存與頁錯誤監控 (-r)

使用 -r 選項可以專注於進程的內存和頁錯誤統計。

# 示例: 每隔 5 秒監控一次所有進程的內存使用情況
pidstat -r 5

# 關鍵輸出列説明：
# minflt/s：每秒次要頁錯誤 (minor page faults)，無需磁盤 I/O
# majflt/s：每秒主要頁錯誤 (major page faults)，需要磁盤 I/O (嚴重影響性能)
# RSS：常駐內存大小 (KB)
# VSZ：虛擬內存大小 (KB)

解釋： majflt/s 是一個極其重要的指標。高 majflt/s 表明進程正在頻繁地從磁盤加載數據到內存，通常是內存不足導致頻繁 Swap 發生，是嚴重性能問題的直接信號。

4.4. 深入 I/O 行為分析 (-d)

這是 pidstat 最有價值的功能之一，專門用於定位 I/O 密集型進程。

# 示例: 每隔 10 秒監控一次所有進程的 I/O 活動
pidstat -d 10

# 關鍵輸出列説明：
# kB_rd/s：每秒從磁盤讀取的數據量 (KB)
# kB_wr/s：每秒寫入磁盤的數據量 (KB)
# Command：進程名稱

解釋： 當系統出現高 I/O 負載（如磁盤燈常亮）時，pidstat -d 能立即指出是哪個進程正在執行大量讀寫操作，這對於數據庫、日誌記錄、備份等場景的性能分析至關重要。

4.5. 任務切換與上下文切換分析 (-w)

上下文切換（Context Switch）過多是導致 CPU 效率低下的常見原因之一。

# 示例: 監控任務和上下文切換情況
pidstat -w 5

# 關鍵輸出列説明：
# cswch/s：每秒自願上下文切換次數 (voluntary context switches)
# nvcswch/s：每秒非自願上下文切換次數 (non-voluntary context switches)

解釋：

• 自願切換 (cswch/s)： 進程主動放棄 CPU，通常是因為它在等待 I/O 或等待鎖。
• 非自願切換 (nvcswch/s)： 進程時間片用完或被更高優先級的進程搶佔。
• 高非自願切換通常意味着 CPU 資源競爭激烈，是 CPU 瓶頸的直接體現。

5. 實戰案例：定位高 I/O 進程

5.1. 傳統 top 的盲區

假設系統磁盤 I/O 負載很高，但 top 命令顯示所有進程的 %CPU 都很低。此時，我們無法判斷瓶頸在哪裏。

# top 截圖 (示例)
# PID   USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
# 1024  mysql     20   0   1.8g   1.2g  150m S   1.2  8.0 125:40.12 mysqld
# 2048  root      20   0   150m    50m  10m R   0.8  0.3 0:05.11  rsync
# ... 很多進程 %CPU 均低於 2%

問題： 表面看 CPU 正常，但磁盤可能已經飽和。

5.2. pidstat -d 的精準定位

使用 pidstat -d 能夠直接穿透 CPU 假象，定位 I/O 罪魁禍首。

# 執行 pidstat -d 5 1
pidstat -d 5 1

# 示例輸出
Linux 4.15.0-20-generic (server-name)    10/26/2025      _x86_64_        (8 CPU)

01:00:00 PM  PID  kB_rd/s  kB_wr/s  Command
01:00:00 PM  1024     0.00     0.00  mysqld
01:00:00 PM  2048   2560.50    0.00  rsync  <-- 明確的讀 I/O
01:00:00 PM  3072     0.00   8192.15  logstash <-- 明確的寫 I/O (每秒 8MB)

Average:     PID  kB_rd/s  kB_wr/s  Command
Average:     1024     0.00     0.00  mysqld
Average:     2048   2560.50    0.00  rsync
Average:     3072     0.00   8192.15  logstash

分析： 立即發現 logstash 進程正在以每秒 8MB 的速度寫入磁盤，rsync 進程以每秒 2.5MB 的速度讀取磁盤。即使它們的 CPU 佔用率很低，但它們是當前的 I/O 瓶頸源頭。

6. 總結與展望

從基礎的 ps 到交互式的 htop，再到專業的 pidstat，我們構建了一個完整的 Linux 進程監控工具鏈。

掌握 pidstat 的 -r、-d、-w 等高級選項，是 Linux 運維工程師和高級開發者邁向性能調優專家的重要一步。未來的進程管理將更加依賴 eBPF 等技術，但基於 procfs 的傳統工具依然是理解系統底層行為不可或缺的基礎。