SQL Server 磁碟吞吐量比 diskspd 慢
這是一個有點寬泛的問題，但我試圖了解我們兩台伺服器的儲存性能行為。
我正在關注https://www.brentozar.com/archive/2015/09/getting-started-with-diskspd/
在一台伺服器上，我在與數據庫相同的磁碟上使用以下參數執行 dskspd。
diskspd.exe -b2M -d60 -o32 -h -L -t56 -W -w0 -c10G G:\MP13\Data\test.dat大約 1400MB/s
我還能夠使用如下的 T-SQL 查詢獲得可比較的吞吐量，並根據讀取次數和時間計算吞吐量。我是從 Glenn Berry SQL Course on PluralSight“提高儲存子系統性能”中得到的。
set statistics io on set statistics time on checkpoint dbcc dropcleanbuffers select count(*) from table1 with(index(1))不過，在另一台伺服器上，我可以從 diskio 工具獲得高吞吐量數字，但使用 SQL 伺服器方法我無法獲得吞吐量數字。如果我在單執行緒中執行 diskspd，則 SQL 編號接近我得到的結果，即使該計劃是並行執行的。
所以我想知道我可以檢查哪些東西來了解為什麼 SQL Server 的 IO 很慢，或者為什麼 SQL Server 無法推動更多的 IO 通過。
有一些概念性的事情需要解決。當您執行像 diskspd 這樣的工具時，您是在對儲存的理論限制進行基準測試，而不是保證查詢的特定性能配置文件。此外，您只測試配置的模式（2MB 塊大小、32 隊列深度、56 個執行緒、100% 讀取
$$ random? sequential? $$）。SQL Server 具有多種讀/寫模式，並且不能保證您的查詢遵循此測試模式。本質上，您正在使用 diskspd 和查詢測試兩種不同的東西。 如果您使用的是 SAN，以下兩點主要是有效的。
此外，不同的儲存工具以不同的方式執行測試。sqlio 使用空字節 (
0x0) 調整 10GB 測試文件的大小。diskspd 似乎有不同的模式，但它仍然重複。
fio大小與隨機數據。我只使用過一次vdbench並且老實說沒有檢查它用於填充文件的內容。我提出這一點是因為大多數 SAN 會壓縮和刪除空白空間和重複模式。因此，您不必在 SAN 上測試類似大小的文件（假設您的 SQL Server 數據文件為 10GB）的性能。可以肯定的是，您的數據文件可以進行壓縮和重複數據刪除，但可能與 diskspd 生成的文件級別不同。
這引出了我想說的最後一點。根據您的 SAN 記憶體大小，通常 10GB 的文件甚至不足以實際測試您的 SAN 性能（從 IOPS 角度來看）。SAN 控制器可能能夠將此 test.dat 文件壓縮和重複數據刪除，使其大小足夠合理，可以放在控制器記憶體中，並且從不實際接觸備份磁碟。因此，您要測試的是 SAN 控制器和作業系統之間的路徑，您已將其確定為 1400MB/s。
我按照 Microsoft 的 Fast Track 數據倉庫戰略部署硬體進行了相同的練習。他們的 SQL Server 2012 快速通道數據倉庫參考指南涵蓋了您發現並已測試的主題，例如針對已在緩衝池中的數據的查詢的 MCR（最大消耗率）和針對實際查詢的 BCR（基準消耗率）其中一些（如果不是全部）數據需要來自磁碟子系統。查詢複雜性也會影響整體吞吐量（使用 TPC-H 基準數據集，他們的範例顯示每個核心的吞吐率從 56 到 201 MB/s）。