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-Offload
VMware の機能を無効にした結果を調査しました。まだテスト中ですが、結果には一貫性がないようです。最初の 'ベンチマーク'の結果は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の待機時間を示しています。