VM）での遅いデータ処理の診断
VMの内部から、明らかに低速で実行されているVMを診断しようとしています。
状況：
- 6コアの12GB仮想マシンで実行されているWindowsServer2008R2にIISでホストされているアプリケーションがあります。
- SQL Server 2008R2 SP3クラスター（16コア以上、16 GB以上のRAM）で実行されているデータベースがあります
- アプリケーションは、このデータベースに対してメッセージのキューを処理しています。処理は主にクエリ/フェッチと更新で構成され、メッセージごとに1ダースほどのラウンドトリップが行われる可能性があります。限られた数のスレッド（3）がこのワークロードに割り当てられ、同期しているため、スレッドはデータベースの応答をブロックします。
- データベースの負荷は明らかに軽く、最大CPU負荷の数パーセントにすぎません。
- 私たちの知る限り、データベースとVMホストの両方が同じデータセンターにあります。
データベースは、非同期ネットワークIOの待機にかなりの時間を費やしたことを報告します。アプリケーションがデータを消費するのを待っています。アプリケーションVMも明らかに負荷が軽い：CPUが約20％。インフラストラクチャは私たちが所有しておらず、仮想マシンへのRDPとデータベースクラスターへのSQL ManagementStudioを介した唯一のアクセスです。 。データベースとVMの両方のパフォーマンスカウンターを記録していますが、プロファイラーを実行するための十分な特権がありません。
数週間前、メッセージ処理率は突然70〜80％低下しました。私たちが知る限り、何も変更されていません。アプリケーションは変更または再構成されておらず、パフォーマンスカウンターは負荷特性の変更を示していません。インフラストラクチャの所有者は、彼らの最後には何も変わっていないと述べています。
再起動プロセスの一部として、アプリケーションはメッセージキューをリロードするように作成されました。これには、数十万行の1つの単純なSELECTが含まれ、その後、メモリ内構造に読み込まれます。データベースは数秒でSELECTを処理しましたが、アプリケーションが結果セットを読み取るまで約10分間待機しました。これは非常に単純な逆シリアル化を伴うシングルスレッド操作であり、このハードウェアでは数分以上かかることはありません。
私の現在の理論では、ネットワーク遅延が何らかの形で増加していますが、pingは「<1ms」のみを報告し、どのような場合でもベースラインはありません。 hrPingは、アプリケーションサーバーからデータベースまで0.5〜2ミリ秒の時間を報告します。
もう1つの可能性は、VMの実際のCPU容量が何らかの方法で減少したことですが、「見かけの」負荷の増加として現れると予想されます。
私たちが利用できる他の調査手段はありますか？
すべての提案をありがとう！ VMホストまたはネットワークの誤動作であるかどうか、またそれを修正するために何が行われたかは不明ですが、状況は最終的に解決されました。
トラブルシューティングの過程で、特定のデータベース操作のプロファイルを作成し、プラットフォームが正常でなかった正確な方法を特定するための簡単なアプリケーションを作成しました。
https://github.com/BluewireTechnologies/db-latency
基本的に、データベースのstatistics time 0ミリ秒が経過したと主張しましたが、SQLクライアントは、ExecuteReader（）が戻るのを数百ミリ秒待って、ネットワークの問題を示しているか、おそらくVMタイムスライス：これらのスパイクは、データベースのラウンドトリップの約5％に影響を与え、通常は瞬時の操作が完了するまでに数秒かかる可能性が高くなります。
お客様の技術者の1人が、ツールを自分でコンパイルして使用しました。彼は私たちの調査結果を確認して適切なチームに転送し、数時間後に問題は解決しました。
誰もが疑っていたように、それはネットワークの問題であった可能性が高いようです。
私はこれまで専門家ではありませんが、ここに私の2セントがあります。
1）疑いを排除する：
DBからアプリサーバーに2つの大きなフォルダーを転送し、その逆で約500MBを転送します。 1フォルダーには、サイズが500MBの単一のバイナリファイルが含まれている必要があります。 2番目のフォルダーには、すべて1KB以下の数千/数百万のファイルが含まれている必要があり、それぞれの場合のネットワークパフォーマンスを確認できます。 1つ目は、パケット数の少ない高ペイロードストリームのシミュレーションを示し、2つ目（DBトランザクションを模倣する）は、パケット数の多い低ペイロードストリームのシミュレーションを示します。これにより、あちらで利用できるネットワーク環境の種類と、ネットワークに関する懸念が正しいかどうかがわかります。スイッチング容量はポート速度だけではないことに注意してください。 10パケットで到着する10MB/sは、100,000パケットで到着する10 MB/sと同じスイッチの負荷（スイッチのCPU使用率）ではありません...スイッチは、ペイロードに関係なくすべてのパケットを転送する必要があり、ネットワークが飽和状態になる可能性があります十分なスイッチング容量（1秒あたりのパケット数）がない場合は簡単に。データセンターではおそらく（99.9％）は当てはまらないでしょうが、テストするまで確実に知ることはできません。
2）2番目のポイントアプリケーション構成：
これがアプリケーションであり、適切に構成されていることを願っています。そうでない場合、ほとんどのJDBCドライバーにはバッチトランザクションがあります。これは、永続性プロバイダーで明示的に定義されていない場合、エクスペリエンスと同様の動作を引き起こす可能性があります（アプリケーションが一定量待機している）実際にトランザクションをコミットする前、またはクエリを実行する前に多数の読み取りを待機する前の書き込みの数）。それでも、これらのバッチ操作には1秒または2秒のオーダーのタイムアウトがあり、バッチキューがいっぱいかどうかに関係なく、トランザクションをコミットします。
）サードポイントクラウド契約の詳細：
これはクラウドプロバイダーなので、細かい部分を確認してください。参照しているトランザクションの種類には、ホストバス上での多数のトランザクションが含まれます。現在、ほとんどのプロバイダーはVM）ごとにバス使用率を制限していますが、正確にアドバタイズしていません（gt/sに制限があります）。したがって、データが到着すると、転送に大きな影響があります。ネットワークインターフェイスからバスを介してVMに到達するRAM（VMはリソースが一致しないため、同じ共有を取得できないため、単純なネットワークワークロードが異なることに注意してください） 。制限されていることを示す良い指標は、1G接続があり、大きなバイナリ連続ファイルを負荷なしでローカルに転送しようとし、50〜60 MB/s（450〜480 Mbps）を達成しないことです。
とにかくそれが役立つことを願っています