Linux 系統高磁盤讀 IO 異常：使用 inotify 定位具體讀取文件

問題背景

項目運行中磁盤讀 IO 飆升導致服務掛掉，`iostat`/`vmstat` 僅能看到設備級別吞吐，無法定位**具體進程讀了哪些文件**。

核心工具：inotify / fanotify (內核級文件系統事件監聽)

不同於用戶態 `strace -e trace=open,read -p PID` (極大性能開銷，生產環境慎用)，`inotify` 由內核推送事件，開銷極低。

實戰腳本：fatrace (基於 fanotify，需 root)

# 安裝
apt-get install fatrace  # Debian/Ubuntu
yum install fatrace      # CentOS/RHEL (需 EPEL)

# 運行：實時顯示所有進程文件讀寫事件
sudo fatrace -t -p $(pgrep -d, -f your_java_app)
# 輸出示例：
# 14:32:15.123456 java[1234]: R /var/log/app.log
# 14:32:15.123567 java[1234]: R /data/index/segment_45.dat

編程接口：C/C++/Go/Python 直接調用 inotify

// C 示例：監聽目錄訪問事件
int fd = inotify_init1(IN_NONBLOCK);
int wd = inotify_add_watch(fd, "/data", IN_ACCESS | IN_OPEN | IN_CLOSE_NOWRITE);
char buf[4096];
while (read(fd, buf, sizeof(buf)) > 0) {
    struct inotify_event *ev = (struct inotify_event*)buf;
    if (ev->mask & IN_ACCESS) printf("PID %d read file: %s\n", getpid(), ev->name);
}

進階：SystemTap / eBPF (BCC) 動態追蹤

• opensnoop (BCC) 實時顯示 `open()` 系統調用：`sudo opensnoop -p PID`。
• biolatency 分析塊設備延遲分布。
• 無需修改代碼、無需重啟進程，生產環境安全。

排查思路

1. 確認是否為 **日志文件瘋狂寫入/讀取**（如未配置滾動、級別過低 DEBUG）。
2. **數據庫索引缺失**導致全表掃描讀取大量數據文件。
3. **內存不足**觸發 Swap，頻繁頁面交換讀寫磁盤。
4. **應用邏輯 Bug**：循環讀取同一文件、未關閉文件句柄洩漏。