SQL Server 2016の奇妙なパフォーマンス問題

VMware仮想マシンで実行されているSQL Server 2016 SP1の単一インスタンスがあります。異なるアプリケーション用の4つのデータベースが含まれています。これらのアプリケーションはすべて別々の仮想サーバー上にあります。それらのどれもまだ実稼働で使用されていません。ただし、アプリケーションをテストする人々はパフォーマンスの問題を報告しています。

これらはサーバーの統計です：

• 128 GB RAM（SQL Serverの場合は110 GBの最大メモリ）
• 4コア@ 4.6 GHz
• 10 GBitネットワーク接続
• すべてのストレージはSSDベースです
• プログラムファイル、ログファイル、データベースファイル、およびtempdbは、サーバーの別のパーティションにあります
• asd

ユーザーは、C ++ベースのERPアプリケーションを介して単一画面アクセスを実行しています。

ostress多くの小さなクエリまたは大きなクエリを使用してMicrosoftでSQL Serverのストレステストを行うと、最大のパフォーマンスが得られます。彼が十分に速く答えることができないので、スロットリングすることだけがクライアントです。

しかし、ユーザーがほとんどいない場合、SQL Serverはほとんど何もしていません。それでも、アプリケーションに何かを保存するために、人々は永遠に待つ必要があります。

ポールランダルの「どこが痛いのか教えて」クエリによると、すべての待機イベントの50％はASYNC_NETWORK_IOです。

これは、ネットワークの問題、またはアプリケーションサーバーまたはクライアントのパフォーマンスの問題を意味する可能性があります。どちらも、最大容量でリソースをリモートで使用していません。ほとんどの場合、CPUはすべてのマシン（クライアント、appserver、dbサーバー）で約26％です。

ネットワーク接続の遅延は約1〜3ミリ秒です。dbサーバーのIOは、アプリケーションで通常の使用中に最大20MB / sの書き込み速度です（avgは7-9MB / sです）。ストレステストを行うと、最大で約5GB /秒になります。

バッファキャッシュサイズは、ERPシステムのDBで60GB、ファイナンスソフトウェアで20GB、品質保証ソフトウェアで1GB、ドキュメントアーカイブシステムで3GBです。

SQL ServerアカウントにInstant File Initializationを使用する権利を与えました。少しでもパフォーマンスは向上しませんでした。

通常の使用中のページの平均寿命は約15k +です。予想される重いストレステストの終了中に約.05kに低下します。バッチ/秒は、ワークロードに応じて約2〜8kです。

私はERPアプリはひどく書かれていると思いますが、すべてのアプリケーションが影響を受けるのでできません。最小限の作業負荷でも。

しかし、私はこれを引き起こしているものを特定することはできません。ヒント、ヒントチュートリアル、アプリケーション、ベスト/ワーストプラクティスドキュメント、またはこの問題に関して皆さんが心に留めておくものはありますか？

これらはからの結果ですsp_BlitzFirst：

600秒実行しました。アプリの負荷が高いときに開始しました。1/3の時間ASYNC_NETWORK_IOです。また、私はとのネットワーク接続をテストしNTttcp、PsPing、ipferf3、とpathping。珍しいことはありません。応答時間は最大3ms、平均0.3msです。スループットは約1000 MB / sです。

私の調査の結果、常にASYNC_NETWORK_IO一番のウェイトスタットになりました。

Large-Receive-OffloadVMware の機能を無効にした結果を調査しました。まだテスト中ですが、結果には一貫性がないようです。最初の 'ベンチマーク'の結果は19分間でした（一番上の結果は、アプリがSQL Server自体を備えたVMで実行されている場合にのみ達成される13分です）。2番目の結果は28分で、これは本当に悪いです。

「ベンチマーク」の最初の結果は19分でした。どっちがいい。一番上の結果は13分だったためです（これは、アプリケーションがSQL Server自体を使用してVMのベンチマークを行った場合にのみ達成可能です）。これは、ネットワーク関連の問題を強く示唆しています。または、VMware構成の問題。

私は現在、どの方法を使用するか、それをボトルネックに絞り込むために迷っています。

アプリの最大パフォーマンスは、アプリがSQL Server自体を備えたVM上で実行されている場合にのみ達成可能です。アプリが他のVMまたは仮想デスクトップで実行された場合、ベンチマークの期間は3倍になります（13分から40分以上）。すべてのエンドポイント（SQL ServerのVM、アプリサーバーのVM、および仮想デスクトップ）は、同じ物理ハードウェアを使用しています。他のすべてのエンドポイントを他のハードウェアに移動しました。

編集：問題が戻ってきたようだ。省エネモードをバランスの取れたモードから高性能に設定した後、実際に応答時間を劇的に改善しました。しかし、今日は300秒のサンプルでsp_BlitzFirstを再度実行しました。これが結果です：

sp_blitzfirstが実行された秒数よりも長い秒数のASYNC_NETWORK_IOの待機時間を示しています。

プライマリ待機がの場合ASYNC_NETWORK_IO、問題はSQL Serverにありません。ほとんどの場合、アプリケーションのボトルネックが原因です。アプリケーションサーバーのボトルネックではなく、アプリケーションのボトルネックを意味します。

通常、アプリケーションのボトルネックは、SQL Serverがデータを送信している間の行ごとの処理が原因です。

• アプリケーションはSQL Serverからデータを要求しています
• SQL Serverはデータを高速で送信しています
• アプリケーションは、各行の処理中に待機するようSQL Serverに指示しています
• SQL ServerはASYNC_NETWORK_IO、アプリケーションが待機するように指示している間、待機時間を記録します

その代わりに、アプリケーションはSQL Serverからすべてのデータを消費する必要があり、THENは行ごとの処理を行います。その時点では、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 ++アプリを修正する必要があります。

私自身の質問に答えるために：ASYNC_NETWORK_IOがSQL Serverでトップ待機タイプとして表示される主な理由energy savingは、Windowsサーバーの設定がの'balanced'代わりに設定されたことです'high performance'。その後、一部のvm ware管理者と話をしましたが、この設定はパフォーマンスを低下させると彼ら全員が言いました。

これに対する解決策は次のいずれかです。

• Windowsサーバーのインストール時にエネルギー制御をインストールしないでください
• グループポリシーを介してすべてのサーバーの省エネモードを高パフォーマンスに設定する

ASYNC_NETWORK_IOに関するその他のすべての問題/統計は、ERPアプリの記述が不適切であることに関連しています。この問題の解決に私を助けてくれたすべての人に感謝します。あなたのコメント、提案、アドバイスは大歓迎で役に立ちました！