SQL Server 2016の奇妙なパフォーマンスの問題
VMware仮想マシンで実行されているSQL Server 2016 SP1の単一インスタンスがあります。それぞれ異なるアプリケーション用の4つのデータベースが含まれています。これらのアプリケーションはすべて別の仮想サーバー上にあります。それらのどれもまだ本番環境で使用されていません。ただし、アプリケーションをテストする人々はパフォーマンスの問題を報告しています。
これらはサーバーの統計です：
- 128 GB RAM（SQL Serverの最大メモリは110GB）
- 4コア@ 4.6 GHz
- 10 GBitネットワーク接続
- すべてのストレージはSSDベースです
- プログラムファイル、ログファイル、データベースファイル、およびtempdbは、サーバーの別のパーティションにあります。
- asd
ユーザーは、C++ベースのERPアプリケーションを介して、単一画面アクセスを実行しています。
Microsoftのostressを使用してSQL Serverをストレステストし、多数の小さなクエリまたは大きなクエリを使用すると、最大のパフォーマンスが得られます。クライアントが十分に速く応答できないため、スロットルのみがクライアントです。
しかし、ユーザーがほとんどいない場合、SQL Serverはほとんど何もしません。しかし、人々はアプリケーションに何かを保存するためだけに永遠に待たなければなりません。
Paul Randalの " Tell me where it痛いところ "クエリによると、すべての待機イベントの50％はASYNC_NETWORK_IOです。
これは、ネットワークの問題、またはアプリケーションサーバーまたはクライアントのパフォーマンスの問題を意味する場合があります。それらのどちらも、リソースを最大容量でリモートで使用していません。ほとんどの場合、CPUはすべてのマシン（クライアント、アプリサーバー、データベースサーバー）で約26％です。
ネットワーク接続の遅延は約1〜3ミリ秒です。 IOは、アプリケーションでの通常の使用中に最大20MB/sの書き込み速度です（平均は7-9MB/sです）。ストレステストを行うと、最大で約5GB/s。
ERPシステムのDBのバッファキャッシュサイズは60GB、ファイナンスソフトウェアは20GB、品質保証ソフトウェアは1GB、ドキュメントアーカイブシステムは3GBです。
SQL Serverアカウントに インスタントファイル初期化 を使用する権利を与えました。それによってパフォーマンスがわずかに向上することはありませんでした。
通常の使用では、ページの平均寿命は約15,000以上です。予想されるヘビーストレステストの終了時に、約.05kに低下します。バッチ/秒は、ワークロードにもよりますが、約2〜8kです。
ERPアプリはひどく書かれていますが、すべてのアプリケーションが影響を受けるのでできません。最小のワークロードでも可能です。
しかし、これを引き起こしている原因を特定することはできません。ヒント、ヒントチュートリアル、アプリケーション、ベスト/ワーストプラクティスドキュメント、またはこの問題に関して皆さんが心に留めていることはありますか？
これらはsp_BlitzFirstの結果です。
600秒実行しました。アプリの負荷が高いときに開始しました。時間の3分の1はASYNC_NETWORK_IOです。また、NTttcp、PsPing、ipferf3、pathpingを使用してネットワーク接続をテストしました。珍しいことは何もありません。応答時間は最大3ミリ秒、平均0.3ミリ秒です。スループットは約1000 MB /秒です。
私の調査の結果、常にASYNC_NETWORK_IOが一番のウェイトスタットになります。
VMwareのLarge-Receive-Offload機能を無効にした結果を調査しました。まだテスト中ですが、結果に一貫性がないようです。最初の「ベンチマーク」の結果は19分の持続時間でした（最上位の結果は13分で、アプリがVMで実行されている場合にのみ達成されます）。2番目の結果は28です。分、それは本当に悪いです。
「ベンチマーク」の最初の結果は19分でした。どっちがいい。上位の結果は13分でした（これは、VMでSQL Server自体を使用してアプリケーションのベンチマークを行ったときにのみ達成可能です）。これは、ネットワーク関連の問題を強く示唆しています。または、VMwareの問題構成。
私は現在、ボトルネックを特定するためにどのような方法を使用するか迷っています。
アプリの最大パフォーマンスは、アプリがVMで実行されている場合にのみ達成できます。アプリが他のVMまたはベンチマークの期間が3倍になる仮想デスクトップ（13分の期間から40分以上に）。すべてのエンドポイント（SQL ServerのVM、VM））が使用しています他のすべてのエンドポイントを他のハードウェアに移動しました。
編集：問題が戻ってきたようです。省エネモードをバランスのとれたパフォーマンスから高性能に設定した後、実際に応答時間を劇的に改善しました。しかし、今日は300秒のサンプルでsp_BlitzFirstを再度実行しました。これが結果です：
これは、sp_blitzfirstが実行された秒よりも、ASYNC_NETWORK_IOの待機時間が1秒多いことを示しています。
私自身の質問に答える：ASYNC_NETWORK_IOがSQL Serverで最上位の待機タイプとして表示される主な理由は、Windowsサーバーのenergy saving設定が'balanced'ではなく'high performance'に設定されたことでした。その後、いくつかのvm ware管理者と話しましたが、彼らは全員この設定によりパフォーマンスが低下すると述べました。
これに対する解決策は次のいずれかです。
- Windowsサーバーのインストール時にエネルギー制御をインストールしない
- グループポリシーを使用して、すべてのサーバーの省電力モードを高パフォーマンスに設定します
ASYNC_NETWORK_IOに関する他のすべての問題/統計は、ERPアプリが不適切に記述されていることに関連しています。この問題の解決に協力してくれたすべての人に感謝します。コメント、提案、アドバイスは非常に歓迎され、役に立ちました！
主な待機がASYNC_NETWORK_IOの場合、問題はSQL Serverにありません。ほとんどの場合、アプリケーションのボトルネックが原因です。アプリケーションサーバーのボトルネックではなく、アプリケーションのボトルネックを意味します。
アプリケーションのボトルネックは通常、SQL Serverがデータを送信している間の行ごとの処理が原因です。
- アプリケーションはSQL Serverにデータを要求しています
- SQL Serverはデータを高速に送信しています
- アプリケーションはSQL Serverに各行を処理する間待機するように指示しています
- SQL Serverは、アプリケーションが待機するように指示している間、
ASYNC_NETWORK_IOに待機時間を記録します
その代わりに、アプリケーションはSQL Serverからのすべてのデータを使用する必要があり、その後、行ごとの処理を行います。 SQL Serverは、現時点ではサポートされていません。
sp_BlitzFirst出力
LCK_M_Sの待機時間は長くありません。 30秒のサンプルの2秒だけがその上にあり、その平均はわずか400ミリ秒です。それが問題になることはほとんどありません。 ASYNC_NETWORK_IOは、そのサンプルでの最大の待機です。それでもアプリケーションの問題。 LCKに関するサポートが必要な場合は、関連するクエリを確認する必要があります。
そのサンプルではASYNC_NETWORK_IOもそれほど悪くありません。待ち時間がサンプルサイズ以上になると目が大きくなります。それは私が掘り下げるときです。
問題全体はASYNC_NETWORK_IOです。これはSQL Serverの問題ではありません。これは、アプリケーション（SQL Serverがデータを送信しているときに行ごとの処理を行う）、アプリケーションサーバー（既に問題がないと言っています）、またはネットワーク（ネットワークは問題ないと言っています）のいずれかに問題があります。したがって、問題はアプリケーションにあります。 C++アプリを修正する必要があります。