SQLIO IOPS/吞吐量統計和 DBCC CHECKDB 操作之間的主要差異

我正在對一個新的 SSD 陣列進行計時試驗，該陣列同時執行 SQLIO 測試和數據庫還原和 DBCC CHECKDB 呼叫的真實工作負載。我發現我的 SQLIO 批處理生成的 IOPS 和吞吐量與我在工作負載中觀察到的結果之間存在重大差異，工作負載只要求我使用 SQLIO 觀察到的結果的一小部分，通常在 5,000 IOPS 範圍內並產生不超過 400 MB/s 的吞吐量。

如果硬體有足夠的容量來處理負載，DBCC CHECKDB 將消耗多少資源是否存在固有限制？我可以嘗試哪些設置來擴展 DBCC CHECKDBs 對 CPU 和磁碟資源的使用？

以下是具體…

從systeminfo

OS Name: Microsoft Windows Server 2012 R2 Standard OS Version: 6.3.9600 N/A Build 9600 System Manufacturer: HP System Model: ProLiant DL580 G7 System Type: x64-based PC Processor(s): 4 Processor(s) Installed. [01]: Intel64 Family 6 Model 46 Stepping 6 GenuineIntel ~1042 Mhz Total Physical Memory: 131,062 MB Network Card(s): 4 NIC(s) Installed. [01]: HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter

SQL 伺服器資訊

Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 Copyright (c) Microsoft Corporation Enterprise Evaluation Edition (64-bit) on Windows NT 6.2 (Build 9200: )

• 3 TB SSD LUN 上的使用者數據庫卷（同一卷上的 Tlogs，但僅因為它是一個 DBCC 盒）
• C 上的系統 DB（tempdb 除外）：在 15k 主軸上使用 RAID 1 的捲
• 1 TB SSD LUN 上的 TempDB 數據文件（32 個文件，總計 80 GB）
• 100 GB SSD LUN 上的 TempDB 日誌文件（一個 10 GB 文件）

使用 SQLIO 的測試腳本，其中參數文件被定向到 3 TB XtremeIO 快閃記憶體陣列 LUN 上的 40 GB 測試文件

sqlio -kW -t8 -s120 -o8 -fsequential -b64 -BH -LS -Fparam.txt sqlio -kR -t8 -s120 -o8 -fsequential -b64 -BH -LS -Fparam.txt sqlio -kW -t8 -s120 -o8 -frandom -b8 -BH -LS -Fparam.txt sqlio -kR -t8 -s120 -o8 -frandom -b8 -BH -LS -Fparam.txt

XtremeIO 陣列的規格 XtremIO - 1 Brick Version: 2.2.3 build 25 Build id: 9585409:HEAD-release-2_2

SQLIO 執行的結果 **C:\SQLIO>sqlio -kW -t8 -s120 -o8 -fsequential -b64 -BH -LS -Fparam.txt** sqlio v1.5.SG using system counter for latency timings, 2211143 counts per second parameter file used: param.txt file L:\testfile.dat with 8 threads (0-7) using mask 0x0 (0) 8 threads writing for 120 secs to file L:\testfile.dat using 64KB sequential IOs enabling multiple I/Os per thread with 8 outstanding buffering set to use hardware disk cache (but not file cache) using specified size: 40000 MB for file: L:\testfile.dat initialization done CUMULATIVE DATA: throughput metrics: IOs/sec: 23118.54 MBs/sec: 1444.90 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 2 Max_Latency(ms): 9 histogram: ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %: 5 7 46 41 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

C:\SQLIO>sqlio -kR -t8 -s120 -o8 -fsequential -b64 -BH -LS -Fparam.txt sqlio v1.5.SG 使用系統計數器進行延遲計時，每秒 2211143 個計數 使用的參數文件：param.txt 文件 L:\testfile.dat 具有 8 個執行緒 (0-7) 使用遮罩 0x0 (0) 8 個執行緒讀取 120來自文件 L:\testfile.dat 的秒數，使用 64KB 順序 IO，每個執行緒啟用多個 I/O，其中 8 個未完成的緩衝設置使用指定大小的硬體磁碟記憶體（但不是文件記憶體）：文件：L:\testfile 為 40000 MB。數據初始化完成累積數據：吞吐量指標：IOs/秒：25160.07 MBs/秒：1572.50 延遲指標：Min_Latency(ms)：0 Avg_Latency(ms)：2 Max_Latency(ms)：8 直方圖：ms：0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %：24 33 12 7 7 9 6 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

C:\SQLIO>sqlio -kW -t8 -s120 -o8 -frandom -b8 -BH -LS -Fparam.txt sqlio v1.5.SG 使用系統計數器進行延遲計時，每秒 2211143 個計數 使用的參數文件：param.txt 文件 L:\testfile.dat 具有 8 個執行緒 (0-7) 使用遮罩 0x0 (0) 8 個執行緒寫入 120秒到文件 L:\testfile.dat，使用 8KB 隨機 IO，每個執行緒啟用多個 I/O，8 個未完成的緩衝設置使用指定大小的硬體磁碟記憶體（但不是文件記憶體）：40000 MB 文件：L:\testfile。數據初始化完成累積數據：吞吐量指標：IOs/sec：153634.35 MBs/sec：1200.26 延遲指標：Min_Latency(ms)：0 Avg_Latency(ms)：0 Max_Latency(ms)：1 直方圖：ms：0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %：100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

C:\SQLIO>sqlio -kR -t8 -s120 -o8 -frandom -b8 -BH -LS -Fparam.txt sqlio v1.5.SG 使用系統計數器進行延遲計時，每秒 2211143 個計數 使用的參數文件：param.txt 文件 L:\testfile.dat 具有 8 個執行緒 (0-7) 使用遮罩 0x0 (0) 8 個執行緒讀取 120來自文件 L:\testfile.dat 的秒數，使用 8KB 隨機 IO，每個執行緒啟用多個 I/O，其中 8 個未完成的緩衝設置為使用指定大小的硬體磁碟記憶體（但不是文件記憶體）：40000 MB 文件：L:\testfile。數據初始化完成累積數據：吞吐量指標：IOs/sec：181107.89 MBs/sec：1414.90 延遲指標：Min_Latency(ms)：0 Avg_Latency(ms)：0 Max_Latency(ms)：5 直方圖：ms：0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %：100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DBCC CHECKDB 不是一個好的儲存測試。它也進行邏輯測試，而不僅僅是從磁碟讀取——例如，它比較同一張表上多個索引之間的數據，以確保它們都具有相同的值。這些檢查會消耗 CPU 週期。

如果您想要更好的純儲存測試，請考慮人為設置一個較低的緩衝池數量，並在多個沒有非聚集索引的大表上同時執行多個 SELECT COUNT(*) 查詢。

是的，在某些情況下，等待主要是 100% OLEDB 並且硬體似乎空閒。就我而言，我嘗試在具有空間索引的 26 GB 表上執行 DBCC CHECKTABLE。它會執行，執行，執行……我將它移到我的工作站（6 核 Zeon，16 GB，帶 2 個 SDD），希望能完成它。它執行得更快，但執行和執行….我嘗試使用 SQL 2012、SP2、跟踪標誌等。普通表上的 DBCC 完成速度比生產中快 7 倍，並且確實在我的磁碟上工作，所以我知道我的硬體有幫助。帶有空間索引的表上的 DBCC 在失敗前執行了一個多星期。（我沒有限制記憶體並讓作業系統餓死。我也有虛擬機和其他東西。）當它執行時，我的機器似乎幾乎空閒。我無法辨識瓶頸。它不是 CPU 或磁碟。一世'

也許您可以使用 DBCC CHECKTABLE 來查看是否有一組選擇的表也具有此行為。

有關我的 DBCC 問題的詳細資訊的 MSDN 連結

引用自：https://dba.stackexchange.com/questions/63596