快閃記憶體上的慢速檢查點和 15 秒 I/O 警告
過去幾週,我們一直在努力尋找可能導致這些 I/O 問題發生和檢查點速度變慢的根本原因。
乍一看,這顯然是一個 I/O 子系統錯誤,而 SAN 管理員應該為此負責。但是最近我們將 SAN 更改為使用全快閃記憶體,但到今天仍然出現錯誤,我不知道為什麼因為每個指標,無論是等待統計資訊還是任何其他指標,我都會執行以檢查 SQL 伺服器是否是可能的罪魁禍首似乎恢復正常。
它並沒有真正加起來。也很可能是其他東西在咀嚼磁碟,SQL Server 在這裡成為受害者……但我不知道是什麼?
數據庫位於可用性組中,並且當這些事件發生時,我們確實會看到角色更改和翻轉以及超時發生。
任何幫助弄清楚這一點將不勝感激。讓我知道是否需要任何進一步的細節。
錯誤消息。以下
SQL Server 遇到了 14212 次 I/O 請求,完成時間超過 15 秒
$$ E:\MSSQL\DATA\ABC.mdf $$在數據庫中$$ ABC $$(7)。作業系統文件句柄為 0x0000000000000D64。最近一次long I/O的偏移量為:0x0000641262c000 SQL Server 遇到了 5347 次 I/O 請求,需要超過 15 秒才能完成歸檔
$$ E:\MSSQL\DATA\XYZ.mdf $$在數據庫中$$ XYZ $$ (7)。作業系統文件句柄為 0x0000000000000D64。最近的long I/O的偏移量是:0x0000506c060000 FlushCache:在 925084 毫秒內清理了 111476 個 buf,62224 次寫入(避免了 19 個新的髒 buf),db 7:0 平均吞吐量:0.94 MB/秒,I/O 飽和度:55144,上下文切換 98407 最後一個未完成的目標:10240,avgWriteLatency 14171 FlushCache:為 db 6:0 平均吞吐量:0.18 MB/秒,I/O 飽和度:10080,上下文切換 20913 最後一個未完成目標:2,avgWriteLatency 3
這是 30 分鐘內的虛擬文件統計資訊:
並等待統計數據:
以下是系統架構師的說明:
我們將高 I/O 密集型工作負載(例如數據庫)的工作負載分開,這樣每台主機只有一個。目前主機的規格是 Dell R730,具有 16 個 Xeon E5-2620 核心(2 個插槽)、512GB 和 2x10G 互連用於儲存。群集或主機上的其他 VM 均未遇到這些問題。虛擬機和工作負載的儲存在 Pure FA-x20 上。
一般系統資訊:
- SQL Server 2012 sp3-cu9(企業版)
- 總記憶體:128 GB
- 總數據庫大小:接近 1 TB
過去幾週,我們一直在努力尋找可能導致這些 I/O 問題發生和檢查點速度變慢的根本原因。
聽起來不錯。你已經收集並切割了微過濾器和 storport 跟踪嗎?如果是這樣,它顯示了什麼?
乍一看,這顯然是一個 I/O 子系統錯誤,而 SAN 管理員應該為此負責。但是最近我們將 SAN 更改為使用全快閃記憶體,但到今天仍然出現錯誤,我不知道為什麼因為每個指標,無論是等待統計資訊還是任何其他指標,我都會執行以檢查 SQL 伺服器是否是可能的罪魁禍首似乎恢復正常。
我想在這裡討論兩個不同的領域。
首先是 SQL Server 本身實際上並沒有對 I/O 做任何事情,它使用典型的 Windows API 將其發佈到 Windows。無論是 ReadFile、WriteFile 還是其中的向量 I/O,都取決於 Windows。SQL Server 保留一個掛起的 I/O 列表,並在不同時間檢查該 I/O 以獲取未完成的狀態。這也是使用典型的 Windows 非同步 I/O 模型完成的。當 I/O 已掛起且未完成時列印該消息,根據Windows超過 15 秒,因為我們正在使用 GetOverlappedResult Windows API 檢查狀態。這意味著,SQL Server 在這件事上並沒有真正的發言權,它是通過 Windows 返回的。
第二項是,僅僅因為它是全快閃記憶體和 10 Gb 光纖並不意味著某些東西沒有設置或配置不正確,驅動程序、過濾器或其他錯誤或項目沒有被命中,或者某些東西不是物理的錯誤的。只是想知道:
- 視窗配置
- Windows 驅動程序,例如正在設置的多路徑和最新版本
- 過濾驅動程序(你知道,磁碟設備,防病毒,備份等)
- 管理程序(如果有)
- HBA 驅動程序
- HBA 韌體
- HBA 配置
- 物理佈線
- 光纖交換
- I/O 組連接/SAN/設備
- SAN/設備的配置
這一切都在 SQL Server 之下,只是 SQL Server 是告訴你它的那個。
數據庫位於可用性組中,並且當這些事件發生時,我們確實會看到角色更改和翻轉以及超時發生。
這是非常好的資訊,儘管它並不一定意味著它是完全相關的。現在,如果它僅在發生故障轉移時發生,那麼這將在問題上得到更多解決,並且在我看來更像是驅動程序等。不喜歡向其拋出大量混合 I/O,因為故障轉移通常會導致重做/撤消和重新同步的發生,這可能是未完成 I/O 的峰值。
任何幫助弄清楚這一點將不勝感激。
除非它是推動高 IOP 的一個查詢或一組查詢,這聽起來不像是 30 分鐘的快照,您只有 737,465 次 I/O 操作,平均為 410 次 IOP(不是那麼高,特別是如果它是快閃記憶體) 查看 SQL Server 內部不會幫助解決這個問題,因為 SQL Server 是信使。
如果還沒有,你會想要收集:
- 微過濾器花費的時間。如果您沒有其他任何東西,這可以通過 WPR (XPerf) 完成。如果 I/O 在過濾器驅動程序中停止,這會有所幫助。
- Storport 跟踪。這將是我們途中的最後一站,也是回程的第一站。這兩個讀數之間的任何時間都是在 Windows 之外花費的時間……它還會向您顯示目標以及另一端可能出現的緩慢位置(但並不總是決定性的)。
如果這些都對診斷或縮小問題範圍沒有幫助,那麼可能是時候使用 Windows 儲存支持打開一張票並收集所有數據,以便大家可以從同一頁面開始。
您提到您正在檢查等待統計資訊和“所有其他指標”。我假設您看到很高
PAGELATCH
並WRITELOG
等待?只是為了仔細檢查,你複習了sys.dm_io_virtual_file_stats
嗎?這就是我在收到這些 15 秒 I/O 消息時開始的地方。使用 Erin Stellato 的優秀文章“虛擬文件統計做什麼,不做什麼,告訴你關於 I/O 延遲”作為關於使用什麼查詢的指南。每 5 或 15 分鐘將該 DMV 的快照記錄到表中。尋找平均停頓/延遲的峰值。
查看讀/寫次數或每次讀/寫的平均字節數是否在這些峰值期間上升。可能是您的維護或使用者查詢使 I/O 子系統充滿了超出其處理能力的流量。這些查詢需要調整,或者維護任務需要分解或移動到一天中的不同時間。
與您的 SAN 管理員合作,查看 SAN 中是否存在與這些時間相關的“嘈雜鄰居”或錯誤。將 SAN 設置與其他 SQL Server 框進行比較 - 可能您在物理連接級別存在吞吐量問題,或者您有需要調整的記憶體設置,或者需要安裝更新等。
我意識到這些是一些一般性的步驟,但希望它能給你一些下一步的方向。
關於這一點:
我們為高 I/O 密集型工作負載(例如數據庫)分離工作負載,這樣我們每台主機只有一個……集群和主機上的其他虛擬機都沒有遇到這些問題
我認為如果 SQL Server 是唯一一個在主機上具有高 I/O 工作負載的伺服器,那麼它是唯一一個看到這些問題的伺服器是有道理的——其他伺服器/應用程序甚至可能不會注意到或有任何報告方式,如果他們正在經歷磁碟延遲。
在您的虛擬文件統計螢幕截圖中,E 驅動器看起來特別有問題。那個驅動有什麼不同嗎?
…用於儲存的 2x10G 互連
你可能有佈線問題。考慮重新安裝它們/確保它們具有牢固的連接。可能更換不同的、已知良好的電纜。如上所述,讓 SAN 團隊檢查記憶體設置和其他配置,以查看此卷/主機與其他 SQL Server VM 是否有任何差異。