avg Disk sec/write 和 io_stall_write_ms 之間的區別
我們有一個帶有最新 CU 的 SQL Server 2016 SP2 Enterprise，數據庫文件分佈在不同的磁碟上。
所以我們有數據、日誌、臨時數據庫和系統數據庫，它們都有自己的驅動器。日期和日誌只包含一個文件。
這些驅動器在全快閃記憶體 SAN 上都有自己的 LUN。為了監控延遲，我每 15 分鐘擷取
sys.dm_io_virtual_file_stats一次，然後使用之前的快照計算延遲。對於寫入延遲，我使用以下計算：
(io_stall_write_ms - lag (io_stall_write_ms,1,0) over (order by checkdate))/(num_of_writes - lag (num_of_writes,1,0) over (order by checkdate)) write_latency我的平均寫入延遲為 10 毫秒，但是當我啟動 perfmon（持續時間設置為 900 秒）並監控平均值時。同一驅動器在同一時間段內的磁碟秒/寫入平均寫入延遲僅為 3 毫秒。
我還擷取了同一時期的等待統計資訊，當我查看 PAGEIOLATCH_EX 等待併計算每次等待所用的時間時，我也得到了大約 3 毫秒的值。
我認為 io_stall_write_ms 表示與 avg 相同。磁碟秒/寫還是我錯過了什麼？
有人可以解釋這種行為嗎？
在閱讀了 Sean Gallardy 的文章後，我使用 Perfmon 設置了 StorPort 跟踪。如何配置您在此處找到的跟踪並使用StorPort-Trace-Reader分析結果。
結果表明確實存在一些延遲。
接下來，我使用Windows Performance Recorder來跟踪“Minifilter I/O 活動”。使用Windows 性能分析器，我發現病毒掃描程序造成了麻煩，即使在進行排除時，也花了很多時間在這些微過濾器上。
解除安裝病毒掃描程序後，問題得到解決。現在我們正在搜尋病毒掃描程序導致問題的原因。
我認為你關於這兩個數字應該匹配的結論是公平的。寫入延遲的測量應該提供與“邏輯磁碟”➡“平均磁碟秒/寫入”性能計數器
sys.dm_io_virtual_file_stats類似的數字。確保您盡可能地比較“蘋果與蘋果”。該 Perfmon 計數器的預設設置是向您顯示所有磁碟的延遲，因此請確保您選擇了您感興趣的磁碟（而不是“Total”）：
同樣，在 SQL Server DMV 端，請確保您只聚合和比較同一磁碟上文件的數據。這
sys.dm_io_virtual_file_stats是為您提供每個文件的數據，這些數據可能跨多個磁碟。可能只是不同測量方式之間的採樣率差異導致了問題。例如，您每 15 分鐘獲取一次 DMV 數據。但大概您正在查看預設 Perfmon 的實時輸出，它將顯示 100 秒內的平均值。可能只是在 15 分鐘間隔記憶體在異常值，導致 DMV 的平均值高於您在 Perfmon 中看到的平均值。要嘗試排除這種情況，您可以（至少暫時）更頻繁地對虛擬文件統計資訊進行採樣，以查看數字是否匹配得更好。
我預計，根據您在 Perfmon 和等待統計中看到的較低延遲相關值，您不會主動遇到磁碟延遲問題，並且您只是對從不同工具獲得的差異測量感到好奇。
如果您遇到問題，您可能需要更深入地了解“SQL Server 和磁碟寫入之間發生了什麼”。微軟高層 Sean Gallardy 在這裡非常深入地討論了這一點：慢速檢查點和 15 秒 I/O 警告對快閃記憶體儲存
