SQLIO IOPS /スループット統計とDBCC CHECKDB操作の間の主な不一致
SQLIOテストと、DB復元とDBCC CHECKDB呼び出しの実際のワークロードの両方を実行する新しいSSDアレイでタイムトライアルを行っています。 SQLIOバッチで生成されたIOPSとスループットの間に大きな不一致が見られ、ワークロードで観察しているものは、ワークロードがSQLIOで観察できたもののほんの一部を要求しているだけで、通常は5,000 IOPSの範囲です。生成するスループットは400 MB/s以下です。
ハードウェアに負荷を処理するのに十分な容量がある場合、DBCC CHECKDBがイベントを消費するリソースの数に関して固有の制限はありますか？ CPUおよびディスクリソースのDBCC CHECKDBの使用を拡大するために、どの設定を試すことができますか？
詳細は次のとおりです...
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 Server情報
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上のユーザーDBボリュームTB SSD LUN（同じボリューム上のTlogsですが、DBCCボックスのためだけです）
- CのシステムDB（tempdbを除く）：15kスピンドルでRAID 1を使用するボリューム
- 1のTempDBデータファイルTB SSD LUN（32ファイル、合計80 GB）
- 100 GB SSD LUN上のTempDBログファイル（10 GBファイル1つ）
SQLIOを使用してスクリプトをテストします。ここで、paramファイルは3上の40 GBテストファイルに転送されますTB XtremeIOフラッシュアレイLUN
_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 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 reading for 120 secs from 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: 25160.07 MBs/sec: 1572.50 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 2 Max_Latency(ms): 8 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+ %: 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 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 8KB random 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: 153634.35 MBs/sec: 1200.26 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 0 Max_Latency(ms): 1 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+ %: 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 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 reading for 120 secs from file L:\testfile.dat using 8KB random 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: 181107.89 MBs/sec: 1414.90 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 0 Max_Latency(ms): 5 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+ %: 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は、失敗するまでに1週間以上かかりました。 （私はメモリを制限せず、OSを枯渇させました。VMやその他のものも実行していました。）実行中、私のマシンはほとんどアイドル状態のようです。ボトルネックは特定できませんでした。 CPUやディスクではありません。これについてバグレポートを提出することを考えています。
おそらく、DBCC CHECKTABLEを使用して、この動作を持つテーブルの選択グループがあるかどうかを確認できます。