SQL Server 遇到時間超過 15 秒的 I/O 請求
在生產 SQL Server 上，我們有以下配置：
3 台 Dell PowerEdge R630 伺服器，合併為可用性組
所有 3 個都連接到單個戴爾 SAN 儲存單元，該儲存單元是一個 RAID 陣列
有時，在 PRIMARY 上，我們會看到類似於以下的消息：
SQL Server 遇到了 11 次 I/O 請求，完成時間超過 15 秒
$$ F:\Data\MyDatabase.mdf $$在數據庫 id 8 中
。作業系統文件句柄是 0x0000000000001FBC。
最新長 I/O 的偏移量為：0x000004295d0000。
長 I/O 的持續時間為：37397 ms。
我們是性能故障排除的新手
解決與儲存相關的特定問題的最常見方法或最佳實踐是什麼？
必須使用哪些性能計數器、工具、監視器、應用程序等來縮小此類消息的根本原因？
可能有可以提供幫助的擴展事件，或者某種審計/日誌記錄？
更新：添加了我自己的答案（見下文），解釋了我們為解決問題所做的工作
我們有類似的設置，最近在日誌中遇到了這些消息。我們使用的是 DELL Compellent SAN。在收到這些幫助我們找到解決方案的消息時，需要檢查以下事項
查看警告消息所指向的磁碟的 Windows 性能計數器，特別是：
- 磁碟平均 閱讀時間
- 磁碟平均 寫時間
- 磁碟讀取字節/秒
- 磁碟寫入字節/秒
- 磁碟傳輸/秒
- 平均 磁碟隊列長度
以上為平均值。如果您在一個驅動器上有許多數據庫文件，這些平均值可能會扭曲結果並掩蓋特定數據庫文件的瓶頸。查看Paul S. Randal 的這個查詢，它從 dmv 返回每個文件的平均延遲
sys.dm_io_virtual_file_stats。在我們的案例中，報告的平均延遲是可以接受的，但實際上我們有許多平均延遲大於 200 毫秒的文件。檢查時間。有沒有圖案？它是否在夜間的某個時間更頻繁地發生？如果是這樣，請檢查當時是否正在執行任何維護作業或任何可能增加磁碟活動並暴露 IO 子系統瓶頸的計劃活動。
檢查 Windows 事件查看器是否有錯誤。如果您的交換機或 SAN 過載或沒有為您的應用程序正確設置，您可能會在此日誌中找到一些消息，最好將此資訊提供給您的 SAN 管理員。在我們的案例中，我們一整天都經常收到 iSCSI 連接錯誤，這暗示了問題所在。
查看您的 SQL Server 程式碼。當您收到這些消息時，您不應立即認為這是 IO 子系統問題並將其傳遞給您的 SAN 管理員。您需要儘自己的一份力量並查看數據庫。您是否經常在大量數據中執行非常糟糕的查詢？索引不好？過多的事務日誌寫入？您可以使用一些開源查詢來對數據庫進行健康檢查，檢查查詢計劃的範例是sp_blitzCache
不要忽視這些。今天，您可能每天會收到幾次……然後幾個月後，當您的工作量增加而您忘記監控它們時，它們開始增加。接收大量此類消息會阻止 SQL Server 訪問某個文件，如果它是tempdb，那就不好了。在我們的例子中，它變得非常糟糕，以至於 SQL Server 自行關閉。
我們的解決方案是將交換機升級到 SAN 交換機。是的，這些都是 SQL Server 中要涵蓋的所有要點。導致我們發現它是開關的原因是我們每天在 SQL Server 上的 Windows 應用程序事件查看器中收到大約 1500 個 iSCSI pdu 斷開連接錯誤。這促使我們的 SAN 管理員對交換機進行了調查。
升級後，iSCSI 錯誤立即消失，所有文件的平均延遲降至 50 毫秒左右，這與應用程序的更好性能相關。考慮到這些要點，希望您能找到解決方案。