如何使用 sar 檢視伺服器歷史效能

當一台 Linux 節點在 02:00 變慢時，即時工具往往已經來不及了。這正是 sar 伺服器歷史效能發揮作用的地方。與其盯著即時快照，不如讓工程師回溯機器在更早時間到底發生了什麼：CPU 時間是否主要消耗在使用者態，記憶體壓力是否把系統推向了交換分割區，磁碟佇列是否已經形成，或者網路流量是否在同一時刻突然飆升。核心思路其實很簡單：持續採集輕量級活動記錄，然後在事故發生後再去讀取它們。落實到實際維運中，這能把「伺服器感覺很卡」這類模糊描述，變成一條真正可以驗證的時間線。

為什麼在即時指標不夠用時 sar 依然重要

許多工程師習慣先用互動式命令，因為它們直觀、即時、熟悉。但它們的弱點也很明顯：時機。一旦某次過載只持續了十分鐘，並且在任何人登入之前就結束了，那麼螢幕上的證據也就隨之消失。歷史採集工具透過把週期性取樣寫入每日檔案，彌補了這個缺口，後續還可以透過有針對性的查詢進行回放。根據 Linux 的 sar 手冊頁，該工具不僅能顯示即時樣本，還能從每日活動檔案中展示已保存的 CPU、記憶體、I/O 和網路統計資訊。

這種工作方式特別適合存在排程任務、備份時段、批次匯入、分析流程，或者使用者行為明顯集中在某個時區的流量高峰場景。因為此時真正的問題通常不是「現在發生了什麼」，而是「故障時段期間發生了什麼」。正是這種思路轉變，讓 sar 在底層維運工作中始終頗受青睞。

sar 如何儲存歷史資料

sar 屬於 sysstat 工具集，並依賴背景資料採集機制。採集器會寫入每日活動檔案，常見路徑是 /var/log/sa。sysstat 手冊說明了其預設命名模式為 saDD，即資料檔案按日期編號；同時也提到，如果需要更長的保留週期，可以切換為基於完整日期的命名格式，例如 saYYYYMMDD。

對維運人員來說，這意味著兩個很實際的結論：

• 只有在事故發生前已啟用採集時，歷史可見性才真正存在。
• 保留策略決定了排查時最早可以追溯到什麼時候。

如果一台主機已經運行了幾個月，但活動採集功能始終沒有啟用，那麼 sar 也無法憑空還原失去的過去。它讀取的是已經記錄下來的系統活動，而不是推斷缺失的遙測資料。

在信任這個工具之前，先確認採集已啟用

在把 sar 納入事故處理流程之前，先確認節點確實在持續記錄資料。一個最小化的檢查流程通常包括以下幾步：

1. 檢查命令本身是否存在。
2. 確認每日檔案是否正在持續更新。
3. 檢查保留策略，避免舊記錄過早消失。

一組簡潔的命令通常就足夠了：

• sar -V
• ls -lh /var/log/sa/
• sar -u

sysstat FAQ 也指出，sar 資料通常保存在 /var/log/sa/saDD 中，一旦這些檔案存在，sar 就能夠顯示其中保存的統計資訊。([sysstat.github.io])

讀取 CPU 歷史資料，而不是靠猜

CPU 通常是排查的第一站，但真正的陷阱在於把一切都粗暴地歸結為「CPU 高」。歷史分析更有效的方式，是把 CPU 狀態拆開來看。透過 sar -u，最值得關注的欄位通常是使用者態時間、系統態時間、閒置時間以及 I/O 等待時間。手冊頁對這些 CPU 使用率視圖有清晰說明，並明確指出 sar 就是為了從保存的每日檔案中展示這類指標而設計的。([man7.org])

常見且值得關注的模式包括：

• 使用者態時間偏高，通常說明應用程式程式碼本身計算密集。
• 系統態時間偏高，可能意味著核心層活動較重，例如封包處理或檔案系統壓力。
• I/O 等待時間偏高，往往說明真正的瓶頸不在 CPU，而在於儲存延遲拖慢了執行。
• 閒置時間在較長時間窗內持續很低，則更接近真實飽和，而不是短時突發。

常用命令示例如下：

• sar -u：檢視當天資料
• sar -u -s 10:00:00 -e 11:00:00：檢視指定時間範圍
• sar -u -f /var/log/sa/sa14：檢視指定保存檔案

更「極客」的做法是做關聯分析。單看 CPU 數值，幾乎從來都不是完整答案。如果 I/O 等待升高且吞吐下降，就應該順著鏈路去看區塊裝置資料，而不是過早把責任推給排程器或執行階段環境。

檢查記憶體壓力，而不只是盯著剩餘記憶體

記憶體排障之所以容易混亂，很大程度上是因為很多人過度執著於某一個「剩餘記憶體」數字。更有價值的歷史記憶體分析，應該關注一段時間內的壓力變化。藉助 sar -r 以及面向交換分割區的視圖，例如 sar -S，你可以觀察系統是否一直保留了足夠餘量、快取是否正常回收，以及在故障時段交換分割區是否被捲入。sar 的相關文件也將記憶體報告列為其標準保存指標之一。([man7.org])

以下訊號通常值得進一步深挖：

1. 記憶體使用量緩慢上升，並且在工作負載結束後仍不回落。
2. 在延遲尖峰出現時，交換分割區使用量同步增長。
3. 快取縮小的同時磁碟讀取增加，這往往暗示工作集正在頻繁抖動。

一個很穩妥的除錯習慣，是把記憶體和磁碟歷史放在一起對照看。一旦交換分割區進入問題現場，延遲就可能出現在距離原始記憶體消耗行程很遠的地方。歷史記錄能幫助你把這種滯後效應拆解清楚。

利用磁碟指標解釋卡頓和長尾延遲

當系統感覺很慢，但 CPU 又沒有被完全打滿時，儲存通常就是下一個重點懷疑對象。sar 提供了區塊裝置活動和傳輸統計資訊，可以幫助判斷機器到底是在計算，還是大多數時間都在等待讀寫完成。維運人員通常會使用 sar -d 檢視裝置活動，使用 sar -b 檢視面向傳輸的彙總資訊。

值得關注的現象包括：

• 交易速率上升，並且與某個批次任務或封存任務的時間一致。
• 讀寫活動明顯不對稱，並且與應用行為特徵吻合。
• CPU 視圖中的 I/O 等待升高，同時區塊裝置活動也在增強。

歷史儲存分析更關注持續性爭用，而不是孤立峰值。一次短暫突發未必有害，而一段持續較長的壓力平台通常就不是小事了。無論是在伺服器租用環境還是伺服器託管環境，這種差異都很關鍵，因為即便節點上的症狀看起來一樣，根因所在層次也可能完全不同。

跨時間視窗追蹤網路行為

網路問題最擅長偽裝成應用問題。一次請求逾時發生後，很多人第一反應是先翻日誌，而不是先看網卡歷史。sar 的價值就在於，它可以透過 sar -n DEV 這類視圖暴露裝置層級計數器。sysstat FAQ 也指出，sar 既可以從保存的資料檔案中報告網路裝置使用率，也可以在即時模式下進行展示。

歷史網路回顧對於發現以下現象很有幫助：

• 與發佈、爬蟲或同步任務相吻合的流量突發。
• 故障時段期間接收或傳送流量的劇烈變化。
• 能夠解釋封包處理型系統態時間升高的介面層級異常。

對於服務地理分布廣泛使用者群的工程師來說，這種視圖尤其有啟發性，因為使用者需求往往會在本地工作時間附近高度集中。一旦這種節律變得可見，容量規劃就能少一些被動補救，多一些主動設計。

查詢精確的故障時間視窗

最有效率的 sar 排查通常都從一個明確時間戳記開始。與其通讀整整一天的資料，不如把查詢範圍收窄到故障發生前、發生時和恢復後的那段時間。這樣做可以顯著提高訊號強度，減少雜訊干擾。

一個實用的排查順序通常如下：

1. 先看故障視窗內的 CPU。
2. 再看同一時間段內的記憶體和交換分割區。
3. 接著對照相同時間戳記下的磁碟和網路活動。
4. 最後才進入行程層級或應用層級工具。

示例命令如下：

• sar -u -s 14:00:00 -e 14:20:00
• sar -r -s 14:00:00 -e 14:20:00
• sar -d -s 14:00:00 -e 14:20:00
• sar -n DEV -s 14:00:00 -e 14:20:00

這種以時間為邊界的方式，能讓輸出更像一份系統行為軌跡，而不是一堵隨意堆疊的計數器高牆。

當今天的資料無關時，直接打開舊的每日檔案

某些故障往往在事後很久才被通報，尤其是在沒有全天候人工值守的環境中。此時，正確做法通常是使用 -f 選項直接打開保存好的每日檔案。sysstat 文件說明，sar 可以顯示此前保存在這些檔案中的統計資訊，而這正是回溯性分析的基礎。

常見示例如下：

• sar -u -f /var/log/sa/sa13
• sar -r -f /var/log/sa/sa13
• sar -n DEV -f /var/log/sa/sa13

如果需要較長保留週期，就應檢查配置的歷史保留策略。sysstat 手冊解釋了，保留由歷史設定控制，超過配置天數的檔案會被自動清理。

當 sar 看起來沒用時，常見的失敗模式有哪些

sar 讓人失望，通常不是因為工具能力不夠，而是因為維運流程出了問題。最常見的陷阱往往非常規律：

• 從未啟用採集，因此根本沒有過去可查。
• 保留週期過短，目標檔案已經輪替消失。
• 查詢了錯誤的指標類別，從而得出錯誤結論。
• 一上來先看平均值，結果錯過了真正藏在時間線裡的尖峰模式。

sysstat FAQ 還記錄了一些請求的活動類型不可用的情況，這通常發生在核心或資料檔案沒有提供預期資料集時。

更好的維運習慣，是把 sar 視為整個工具堆疊中的一層：

1. 先用 sar 重建時間軸。
2. 再用行程層級工具識別是誰主導了這條時間軸。
3. 只有在搞清楚系統層級模式後，再去讀日誌和追蹤資料。

生產環境排查的最佳實務

如果能配合一套有紀律的事故處理流程，歷史監控的價值會被放大許多。以下習慣通常很值得堅持：

• 記錄症狀開始和結束的精確分鐘。
• 保留足夠長的歷史，以涵蓋延遲通報的故障。
• 在同一時間片內同時檢視 CPU、記憶體、磁碟和網路。
• 優先解釋趨勢，而不是執著於孤立峰值。
• 在需要更深層離線分析時匯出記錄。

更廣義的 sysstat 工具集還包含用於格式化保存資料的實用程式，相關手冊頁也說明了這些每日檔案除了直接在終端讀取之外，還可以被進一步消費和處理。

結論

優秀的效能排障，始於一條清晰的時間線，而這正是 sar 伺服器歷史效能所能提供的價值。它把一台 Linux 主機從黑盒，變成一份關於狀態轉移的記錄：CPU 繁忙、記憶體吃緊、儲存擁堵，或者網路激增。對於技術團隊來說，它的價值不在於花俏的儀表板，而在於鑑識式的清晰度。如果節點在無人注視時出現異常，sar 就能幫你重播系統自己的敘述，讓整個調查過程少一些猜測、少一些玄學，並且更高效地從症狀走向根因。