SQL 2016低TPMとHammerDB-Test
新しくインストールしたMSSQL 2016サーバーで問題が発生しました。サーバーは、VMwareのベストプラクティスを使用した仮想VMwareマシンです。 TPC-C標準でTPMをテストするために、HammerDB-Toolを使用しました。残念ながら、私たちは約130.000 TPMに達しています。新しいソフトウェアの場合、200.000 TPMを超える最小値に到達する必要があります。
これまでに確認したドライブを個別にテストすると、SQL-Serverはデータベースドライブの全体をフルに使用していません（1.2 GB /秒のIOMeterで全体を取得しています）。
* IOMeterのパラメーターは次のとおりです：12ワーカー、40000000セクター、卓越したI/Oの数16
ここにいくつかの新しい値があります：
64 KiB; 0％読み取り。 0％ランダム
IOPS: 14023 Total MBs per Second: 914.56 MBPS Average I/O Response Time (ms): 13.75 Maximum I/O Response Time (ms): 161.40
64 KiB; 50％読み取り。 0％ランダム
IOPS: 14412 Total MBs per Second: 944 MBPS Average I/O Response Time (ms): 13.30 Maximum I/O Response Time (ms): 413.59
64 KiB; 100％読み取り。 0％ランダム
IOPS: 14280 Total MBs per Second: 936.15 MBPS Average I/O Response Time (ms): 13.44 Maximum I/O Response Time (ms): 173.95
データベース用ディスクは64kbのブロックサイズでフォーマットされています。
サーバー上でCPUとメモリも100％使用されません（NUMA-Node1のテストではリソースの20％しか消費されませんが、NUMA-Node2は5％未満です）。 HammerDBテストの実行中、完全なシステムは約5GBのRAMを使用します。オペレーティングシステムとSQL-Serviceは、MicrosoftとHammerD-Toolの推奨事項に従って構成されています。
仮想マシンのその他の仕様は次のとおりです。5台のHDドライブ（OS、DB、TempDB、Log、TempLog;各ドライブは、VMに分離された準仮想SCSIコントローラーによって接続されています）2それぞれ6つのCPUを搭載したソケット128 GB RAM（110はMSSQL用に予約済み）Windows Server 2012 R2標準オペレーティングシステム。10人の仮想ユーザーでHammerDB-Testを実行すると、CPU使用率は次のようになります。写真に見られる：
私たちの仮想環境とSANは8 Gb /秒のファイバーチャネル接続で接続され、各ホストはSANへの2つの接続を取得しました。各ホストには、2,6 GHzの32個の物理CPUがあります。 SANサーバーとデータを保存するためにSSD Raid10 LUNを構成しました。テストのために、ホストに他のマシンがなかったため、オーバーコミットはありませんでした。すべての構成パラメーターは高に設定されています- BIOSレベルからWindowsレベルまでのパフォーマンス。
SQL構成について：MAXDOPは0に設定されています。「アドホックワークロードの最適化」は有効になっていません。 「メモリ内のページのロック」がSQL-Service-Accountに設定されています。サーバーにリソースガバナーポリシーを追加していません。
これで、CPU、SOCKETあたりのCPU、RAMおよびMAXDOPを使用して、いくつかのさまざまな構成をテストしました。以下の表では、テストした構成ごとにTPMとして結果を確認できます。
| RAM | CPU/SOCKET | SOCKETS | MAXDOP | TMP MIN. | TMP MAX. | TMP AVG. |
|------|------------|---------|--------|-----------|----------|----------|
| 128 | 8 | 1 | 0 | 88,000 | 100,000 | 93,000 |
| 128 | 8 | 1 | 1 | 85,000 | 92,000 | 88,500 |
| 128 | 8 | 1 | 2 | 85,000 | 94,000 | 91,000 |
| 128 | 8 | 1 | 4 | 92,000 | 103,000 | 98,000 |
| 128 | 8 | 1 | 6 | 92,000 | 104,000 | 98,700 |
| 128 | 8 | 1 | 8 | 92,000 | 101,000 | 97,600 |
|------|------------|---------|--------|-----------|----------|----------|
| 128 | 12 | 1 | 0 | 115,000 | 129,000 | 125,400 |
| 128 | 12 | 1 | 1 | 127,000 | 142,000 | 134,300 |
| 128 | 12 | 1 | 2 | 112,000 | 128,000 | 120,900 |
| 128 | 12 | 1 | 4 | 114,000 | 128,000 | 120,800 |
| 128 | 12 | 1 | 6 | 125,000 | 132,000 | 128,800 |
| 128 | 12 | 1 | 8 | 125,000 | 138,000 | 131,300 |
| 128 | 12 | 1 | 10 | 130,000 | 141,000 | 136,200 |
| 128 | 12 | 1 | 12 | 123,000 | 133,000 | 128,100 |
|------|------------|---------|--------|-----------|----------|----------|
| 128 | 4 | 2 | 0 | 83,000 | 96,000 | 92,600 |
| 128 | 4 | 2 | 1 | 82,000 | 90,000 | 85,600 |
| 128 | 4 | 2 | 2 | 85,000 | 95,000 | 88,900 |
| 128 | 4 | 2 | 4 | 94,000 | 100,000 | 97,800 |
| 128 | 4 | 2 | 6 | 87,000 | 100,000 | 95,500 |
| 128 | 4 | 2 | 8 | 94,000 | 102,000 | 97,400 |
|------|------------|---------|--------|-----------|----------|----------|
| 128 | 6 | 2 | 0 | 115,000 | 129,000 | 119,500 |
| 128 | 6 | 2 | 1 | 117,000 | 142,000 | 129,300 |
| 128 | 6 | 2 | 2 | 120,000 | 128,000 | 125,200 |
| 128 | 6 | 2 | 4 | 125,000 | 134,000 | 128,800 |
| 128 | 6 | 2 | 6 | 123,000 | 131,000 | 129,100 |
| 128 | 6 | 2 | 8 | 125,000 | 138,000 | 132,800 |
| 128 | 6 | 2 | 10 | 125,000 | 136,000 | 131,900 |
| 128 | 6 | 2 | 12 | 129,000 | 141,000 | 134,700 |
|------|------------|---------|--------|-----------|----------|----------|
| 128 | 16 | 1 | 0 | 111,000 | 128,000 | 119,300 |
| 128 | 16 | 1 | 12 | 129,000 | 138,000 | 134,900 |
| 128 | 16 | 1 | 16 | 122,000 | 133,000 | 127,900 |
|------|------------|---------|--------|-----------|----------|----------|
| 64 | 12 | 1 | 0 | 116,000 | 128,000 | 121,800 |
| 64 | 12 | 1 | 1 | 132,000 | 145,000 | 138,300 |
| 64 | 12 | 1 | 2 | 123,000 | 134,000 | 128,200 |
| 64 | 12 | 1 | 4 | 118,000 | 133,000 | 125,800 |
| 64 | 12 | 1 | 6 | 123,000 | 134,000 | 129,400 |
| 64 | 12 | 1 | 8 | 128,000 | 138,000 | 133,300 |
| 64 | 12 | 1 | 10 | 114,000 | 133,000 | 124,400 |
| 64 | 12 | 1 | 12 | 127,000 | 134,000 | 131,400 |
|------|------------|---------|--------|-----------|----------|----------|
サーバーをsp_BlitzFirstでテストしました。しかし、私はそれらを正しく解釈するにはあまりにも知っています。これで、CXPACKETSがCPUがアイドル状態であることを意味することがわかりました。他のすべての値については、あなたの助けが必要です:(
アクティビティモニターを見ると、ロックが待機状態に最も影響を与えていることがわかります。しかし、現時点では、ロックを削減するための2つの可能性があると私は考えています。a）サーバーのパフォーマンス全体を高速化するため、ページを再度読み取る必要があるときにロックされません。 b）ソフトウェアを変更します。実際のオプションはありません。以下は、HammerDBテスト中のアクティビティモニターの結果です。
この時点では、サーバーの何が問題なのかわかりません。 200.000 TPMに対応できる、より低いリソース/電力のインフラストラクチャが他にも見られますが、仮想化にHyper-Vを使用している点だけが異なります。
誰かが私たちを助けてくれることを願っています。
敬具
あなたはたくさんのことを書きましたが、ここにあなたの主な質問があります：
TPCベンチマークの数値が予想と異なるのはなぜですか？
その答えを見つけるには、ワークロードの実行中にSQL Serverの待機統計を確認してください。それらはsys.dm_os_wait_statsに格納されますが、累積数としてのみなので、重いワークロード中に差分を行うために sp_BlitzFirst と書きました。次のように実行します。
sp_BlitzFirst @ExpertMode = 1, @Seconds = 30
また、テスト中のサーバーの待機の30秒のサンプルをキャプチャします。待機統計セクションを見て、サーバーが待機しているものを特定し、結果のその部分の画像を投稿して、さらにヘルプを取得してください。
ボトルネックは、ストレージまたはCPUではない可能性があります。待機統計はそれを見つけるための鍵です。
HammerDBサイトのドキュメントセクションには多くの情報があります。特にSQL Server OLTPベストプラクティスガイドです。いくつかの基本的なチェックを行う必要があります。ボトルネックを特定します。1.レポートされるTPMは平均であることを覚えておいてください。テスト中にHammerDBトランザクションモニターを実行すると、TPMが上昇し、直線的で安定したラインに達するか、「ピークと谷」があるかどうかを確認します。後者の場合、これがボトルネックの最初の兆候であり、ワークロードが停止して開始しています。2。テスト実行中にSQL Server Management Studio-上の行を右クリックし、[アクティビティモニター]を選択します-このスクロールダウンで[リソース待機]に移動します-最上位の待機カテゴリと待機時間は何ですか？3.ベストプラクティスガイドで参照されているFusionIOが提供するスクリプトを実行して、これらの待機イベントをドリルダウンし、システムが待機している場所を詳細に確認します。次に、ボトルネックを解決するための手順を実行します-たとえば「ロギング」が一番上にある場合ガイドに従ってログを最適化し、より高速な書き込みスループットをサポートできるデバイスにログを移動することを検討してください。テスト、識別、解決のプロセスを続行します。CPUがほぼ完全に使用されている場合、これがピークパフォーマンスになります。