如何判斷 linux 磁碟 IO 是否導致過多（> 1 秒）應用程序停止

我有一個 Java 應用程序執行大量（數百 MB）連續輸出（流式純文字）到ext3 SAN 文件系統的十幾個文件。有時，此應用程序會一次暫停幾秒鐘。我懷疑與ext3 vsfs（Veritas Filesystem）功能（和/或它如何與作業系統互動）相關的東西是罪魁禍首。

我可以採取哪些步驟來證實或反駁這個理論？我知道iostat並/proc/diskstats作為起點。

修改標題以淡化日記並強調“攤位”

我做了一些Google搜尋，發現至少一篇文章似乎描述了我觀察到的行為：解決 ext3 延遲問題

附加資訊

• 紅帽企業 Linux 伺服器 5.3 版 (Tikanga)
• 核心：2.6.18-194.32.1.el5
• 主要應用磁碟是光纖通道 SAN：lspci | grep -i fibre>>14:00.0 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03)
• 掛載資訊：type vxfs (rw,tmplog,largefiles,mincache=tmpcache,ioerror=mwdisable) 0 0
• cat /sys/block/VxVM123456/queue/scheduler>>noop anticipatory [deadline] cfq

我的猜測是，還有其他一些程序會佔用磁碟 I/O 容量一段時間。 iotop如果您有足夠新的核心，可以幫助您查明它。

如果是這種情況，則與文件系統無關，更不用說日誌了。I/O 調度程序負責在衝突的應用程序之間進行仲裁。一個簡單的測試：檢查目前調度程序並嘗試不同的調度程序。它可以即時完成，無需重新啟動。例如，在我的桌面上檢查第一個磁碟（/dev/sda）：

cat /sys/block/sda/queue/scheduler
=>  noop deadline [cfq]

表明它正在使用 CFQ，這對於台式機來說是一個不錯的選擇，但對於伺服器來說卻不是那麼好。最好設置“截止日期”：

echo 'deadline' > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
=>  noop [deadline] cfq

並等待幾個小時，看看它是否有所改善。如果是這樣，請在啟動腳本中永久設置它（取決於發行版）

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