☰

IRP_MJ_WRITE 延遲長達 15 秒

tag-icon • tag-icon performance monitoring ntfs latency write
IRP_MJ_WRITE 延遲長達 15 秒

我們編寫了一個應用程序，它可以在同一本地捲 (RAID1) 上同時對多個文件執行小量 (22kB) 寫入（一個線程代表其他線程對多個位置執行非同步排隊寫入）。
99.9% 的寫入都是低延遲的，但偶爾（可能每分鐘一兩分鐘）我們會得到一兩次巨大的延遲寫入（我見過 10 秒及以上），而沒有任何真正的解釋。

平台：Win2003 Server，NTFS。
監控：Sysinternals Process Monitor（請參閱下面的連結）和我們自己的應用程式日誌記錄。

我們嘗試了多種方法來嘗試解決這個問題，這些方法是從一些網站收集的，例如：

  • 使檔案名稱的第一部分唯一以幫助 8.3 名稱生成

  • 將檔案寫入多個目錄

  • 更改英特爾磁碟寫入快取

  • Windows 檔案/印表機共用

    • 最小化記憶體使用

    • 平衡

    • 最大化檔案共享的資料吞吐量

    • 最大化網頁應用程式的資料吞吐量

  • 系統->高級->性能->高級

  • NtfsDisableLastAccessUpdate - 使用fsutil行為設定disablelastaccess 1

  • 停用 8.3 名稱產生 - 使用「fsutil 行為設定disable8dot3 1」+重新啟動

  • 啟用大容量檔案系統快取

  • 禁用內核程式碼的分頁

  • IO頁面鎖定限制

  • 關閉（或開啟）索引服務

但似乎沒有什麼太大的差別。有很多事情我們還沒有嘗試過，但我們想知道是否有人遇到過同樣的問題，原因和解決方案（程序化或非程序化）？

我們可以使用 IOMeter 和簡單的設定重現問題：

  1. 啟動 IOMeter 並使用斷開按鈕刪除「拓撲」中除第一個工作執行緒之外的所有執行緒。

  2. 選擇工作線程，在「磁碟目標」標籤中要使用的磁碟旁的方塊中打叉，然後在「最大磁碟大小」中輸入「2000000」（注意：必須至少有1GB 可用空間；磁區大小為512位元組)

  3. 接下來建立一個新的存取規範並將其新增到工作線程中：

    • 傳輸請求大小 = 22kB

    • 100% 順序

    • 訪問規格百分比 = 100%

    • 讀/寫百分比 = 100% 寫入

  4. 將結果顯示更新頻率變更為 5 秒，測試設定運行時間變更為 20 秒，並將「自動產生的工作人員數量」設為零。

  5. 在“拓撲”面板中選擇“工作執行緒”，然後按一下“複製工作執行緒”按鈕 59 次，以建立 60 個具有相同設定的執行緒。

點擊“Go”按鈕（綠色標誌）並監控“結果”標籤。在我們的機器上，「最大 I/O 回應時間 (ms)」始終至少達到 3500。我們的機器並不慢（Xeon 8 核機架伺服器，具有 4GB 和板載 RAID）。

我很想看看其他人會得到什麼。我們感覺這可能與 NTFS 檔案系統有關（我們的檔案系統目前 75% 都充滿了碎片檔案），我們將圍繞這項原則嘗試一些事情。但它也與磁碟效能有關，因為我們在 RAMDisk 上看不到它，而且在 RAID10 陣列上也沒有那麼嚴重。

任何幫助深表感謝。
理查

右鍵單擊並選擇“在新分頁中開啟連結”：
過程監控結果

答案1

我現在有關於這個問題的更多資訊。

使用各種硬體在12 台不同的機器上測試了所描述的IOMeter 測試後，我將其範圍縮小到特定的RAID 晶片組（具有相同晶片組的3 台不同機器使用RAID1 和RAID10 表現出這種行為）。所有其他機器的結果至少好一個數量級。

晶片組：Intel 631xESB/632xESB SATA RAID（又稱 ESB2）

請參閱英特爾網站上的這篇文章以了解更多信息，並希望英特爾能做出回應：
Intel 631xESB/632xESB SATA RAID（又稱 ESB2）寫入速度慢

理查

相關內容