Linux
如何判斷 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
並等待幾個小時,看看它是否有所改善。如果是這樣,請在啟動腳本中永久設置它(取決於發行版)