Sql-Server

快閃記憶體上的慢速檢查點和 15 秒 I/O 警告

  • April 4, 2019

過去幾週,我們一直在努力尋找可能導致這些 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 光纖並不意味著某些東西沒有設置或配置不正確,驅動程序、過濾器或其他錯誤或項目沒有被命中,或者某些東西不是物理的錯誤的。只是想知道:

  1. 視窗配置
  2. Windows 驅動程序,例如正在設置的多路徑和最新版本
  3. 過濾驅動程序(你知道,磁碟設備,防病毒,備份等)
  4. 管理程序(如果有)
  5. HBA 驅動程序
  6. HBA 韌體
  7. HBA 配置
  8. 物理佈線
  9. 光纖交換
  10. I/O 組連接/SAN/設備
  11. SAN/設備的配置

一切都在 SQL Server 之下,只是 SQL Server 是告訴你它的那個。

數據庫位於可用性組中,並且當這些事件發生時,我們確實會看到角色更改和翻轉以及超時發生。

這是非常好的資訊,儘管它並不一定意味著它是完全相關的。現在,如果它僅在發生故障轉移時發生,那麼這將在問題上得到更多解決,並且在我看來更像是驅動程序等。不喜歡向其拋出大量混合 I/O,因為故障轉移通常會導致重做/撤消和重新同步的發生,這可能是未完成 I/O 的峰值。

任何幫助弄清楚這一點將不勝感激。

除非它是推動高 IOP 的一個查詢或一組查詢,這聽起來不像是 30 分鐘的快照,您只有 737,465 次 I/O 操作,平均為 410 次 IOP(不是那麼高,特別是如果它是快閃記憶體) 查看 SQL Server 內部不會幫助解決這個問題,因為 SQL Server 是信使。

如果還沒有,你會想要收集:

  1. 微過濾器花費的時間。如果您沒有其他任何東西,這可以通過 WPR (XPerf) 完成。如果 I/O 在過濾器驅動程序中停止,這會有所幫助。
  2. Storport 跟踪。這將是我們途中的最後一站,也是回程的第一站。這兩個讀數之間的任何時間都是在 Windows 之外花費的時間……它還會向您顯示目標以及另一端可能出現的緩慢位置(但並不總是決定性的)。

如果這些都對診斷或縮小問題範圍沒有幫助,那麼可能是時候使用 Windows 儲存支持打開一張票並收集所有數據,以便大家可以從同一頁面開始。

您提到您正在檢查等待統計資訊和“所有其他指標”。我假設您看到很高PAGELATCHWRITELOG等待?只是為了仔細檢查,你複習了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 是否有任何差異。

引用自:https://dba.stackexchange.com/questions/233705