快閃記憶體上的慢速檢查點和 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 是否有任何差異。