如何分類 linux 磁碟 IO 系統範圍的“掛起”

我有一個定期“出去吃午飯”的盒子。症狀是任何需要實際磁碟 IO 掛起 30 多秒的東西，並且看起來任何已經分頁的東西都沒有受到影響。該問題間歇性地發生，最多每小時發生幾次），並且到目前為止還無法追溯到任何正在執行的程序或使用者行為。現在重新成像盒子將是一個很大的破壞，所以我希望隔離這個問題並希望證明這是不必要的。帶有 btrfs-on-luks nvme root fs 的 Ubuntu 20.04 系統。

使用者描述 + 日誌分析 (dmesg和journalctl) 沒有顯示任何與問題相關的行為，除了 10 秒後的 io-timeout 相關消息，這些消息似乎顯然是症狀/後果。該盒子在 ubuntu 20.04 中使用了大約 6 個月（沒有記錄此問題的實例），幾個月前重新映像，所以我有一個小數據點，表明問題沒有失敗。 btrfs scrub並且biossmart不報告任何錯誤。

在復製過程中使用iotop -olive 我可以看到磁碟的實際吞吐量下降到 ~ 零，除了幾個核心執行緒[kworker/.*events-power-efficient]。

請推薦後續步驟來分類/隔離 IO 掛起的原因。

---

根據要求的智能輸出：

#> smartctl -a /dev/nvme0n1` as requested:
[...]
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        33 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    4,339,623 [2.22 TB]
Data Units Written:                 7,525,333 [3.85 TB]
Host Read Commands:                 23,147,319
Host Write Commands:                69,696,108
Controller Busy Time:               1,028
Power Cycles:                       98
Power On Hours:                     3,996
Unsafe Shutdowns:                   25
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

---

按照@anx 的建議使用netdata，我越來越接近：在我能看到的所有情況下，核心記憶體中的以下症狀似乎與再現 100% 相關。在約 1 分鐘的不可回收核心分配記憶體的過程中 ~加倍。在這一切都被分配期間，~所有 IO 都被掛起。當記憶體被釋放時，IO 有時會在下坡道上解除阻塞。中心峰值/倍增非常一致，之前和之後的較小峰值略有不同。

此外，這種行為以（間歇性）每小時的節奏發生：

致力於清點每小時執行的 cron 和 systemd 任務。查看是否有任何可以啟用的調試日誌記錄，因為今天在這些時間日誌中沒有任何可疑之處。

模式（降級何時發生？）和相關指標（降級期間是否有任何其他指標急劇下降/飆升？）通常是辨識觸發因素的最快途徑。

即使觸發器不是導致問題的原因（例如，如果系統因記憶體壓力而停止，但這樣做的機制更複雜），有一個可靠的再現方法是有幫助的，因此您可以獲得更多數據。

分診步驟：

1. 使用類似netdata視覺化確定模式和/或相關指標的工具。當問題發生時，性能指標是否會發生任何事情？最有用的問題可能出現在性能下降之前- 您看到的問題很可能是某些驅動程序或程序行為不端的恢復階段。
2. 如果您無法發現觸發器並因此沒有故意重現，您可能仍會確定一種確定問題何時再次發生的方法（例如，在下一次大磁碟寫入時，每天 12:00，..）
3. top安排任務，確保您在事件期間（例如，甚至）獲得相關係統狀態的快照（或每 X 個時間單位一個echo t >/proc/sysrq-trigger ; dmesg）。至少手動執行一次計劃任務，以便記憶體其依賴項

常見解釋的想法：

1. 錯誤的交換配置或某些不合適的塊設備堆棧上的交換文件
2. 一個壞硬碟，不一定是包含根文件系統的硬碟
3. 遺留的一些調試任務，例如在 cronjob 中刪除記憶體
4. 一個數據庫，在做家務任務時會消耗可笑的記憶體或訪問一個巨大的目錄
5. SSD trim ( discard)，或缺少它加上大量寫入使系統等待磁碟完成

引用自：https://serverfault.com/questions/1050079