サーバーパフォーマンスとアプリケーション監視のトラブルシューティング–実際の例。

デモサーバーのXNUMXつが遅い理由と、LogicMonitorを使用して問題を特定する方法について社内で質問がありました。 質問する人は、LinuxではなくVoIP、ネットワーキング、およびWindowsのバックグラウンドから来ているため、彼の質問は、経験の浅いシステム管理者（この場合）の質問を反映しています。 彼が彼の思考プロセスを文書化したことは興味深いと思いました。同じデータの解釈と、LogicMonitorがなぜそれが警告するのかについてのいくつかの考えを散りばめます…

最近、デモサーバーの速度が遅いことに気付いたので、LogicMonitorを使用してこのデモサーバーのパフォーマンスのトラブルシューティングを試みました。 1.私の最初のステップは、ホストがどれだけビジーであるかを確認することです。CPU使用率から始めましょう。 ズームアウトしてXNUMXか月のビューを表示しました。

両方のIOWaitPercentが増加していることがわかります。 最初の注意：私はIOWaitカウンターを本当に理解していません。 どういう意味ですか？ 気にする必要がありますか？

これはおそらくここでの問題です。 データソースに記載されているように、IOWaitは「CPUがIOの待機に費やした「ティック」（通常は1/100）の数」です。 そのため、CPUには何かすることがありましたが、それを実行する前に、ディスク上のデータ（またはデータをディスクに置く）が必要でした。 （補足として、監視がこのシステムにとって重要なメトリックを追跡していることを確認するために、アプリケーション固有の監視（要求ごとの応答時間）から始めました。）

では、なぜLogicMonitorは、IOWaitだけが高い場合ではなく、CPUがビジーである合計パーセントについて警告するのでしょうか。 そうですね、ディスクの読み取りまたは書き込みが遅い場合は、ディスクパフォ​​ーマンスモニタリングからのアラートが表示されます。これはより適切なアラートです。 IO待機に関するアラートは、十分でもノイズフリーでもありません。 16コアシステムで実行されているシングルスレッドを使用してデータをディスクにフラッシュまたは読み取るアプリケーションは、その7つのスレッドがほとんどの時間をIO待機に費やしている場合、完全に停止する可能性がありますが、報告されたシステムのIO待機はわずか1％（CPUの16/7のみがディスクIOを待機しているため）。 IOWaitに60％のアラートを設定すると、明らかに多くのノイズが発生します。 別のアプリケーションには書き込み用の優れたバッファリングシステムがある可能性があるため、XNUMX％のIO待機はアプリケーションの応答にまったく影響を与えない可能性があります。 （たとえば、DBがメモリに収まるデータベースですが、多くの更新があります。クエリは引き続き高速で、書き込みは最終的にフラッシュされます。）

ただし、ベースラインとは異なる上記のような変更は、パフォーマンスに影響を与える可能性があります。アプリケーションの特性を理解していない限り、IO待機の増加が懸念の原因であると想定する必要があります。

2.次のステップは通常、このホストを通過するデータの量を確認することです。

ここに手がかりはありません-トラフィックレートは過去30日間変化しませんでした。

うーん。 失礼ですが同意できません。 私には、インバウンドトラフィックが月ごとに大幅に変化しているように見えますが、アウトバウンドトラフィックに対応するように設定されたスケールではわかりません。 そこで、インタラクティブグラフを使用して、アウトバウンドトラフィック（サーバーからのダウンロードなどを含む）をオフにしたので、インバウンドトラフィックが見やすくなりました。

これで、インバウンドトラフィックが基本的に先月のXNUMX倍になったことが明らかであるため、アプリケーションはXNUMX倍のデータを処理しています。

3.メモリ使用量を確認しました。メモリ使用量を変更せずに、スワップレートが奇妙に低下しました。 理由はわかりませんが、サーバーの速度が低下することはないので、無視します。

まあ、正しい質問、間違ったツール。 アクティブスワッピングは確かにシステムパフォーマンスを低下させる可能性があります。 ただし、スワップの使用は、アクティブなスワップがあることを意味するものではありません。 確認する正しいグラフは、スワップの使用量ではなく、スワップレートです。
しかし、それは最小のスワップレートを示しているので、それは問題ではありません。 （もしそうなら、警告があったでしょう。）

4.ディスクIOを確認しました。 わずかに増加しますが、劇的ではないため、おそらく無関係です。

ドライブシステムのIOps容量の限界に近づいていないことがわかっていれば、関係ありません。 この場合、このデモサーバーには1つの15KSASディスクのRAID320があります。したがって、XNUMX秒あたりXNUMXの書き込み操作がほぼ確実に最大機能に達し、パフォーマンスに変曲点が生じます。

この時点で、より多くの情報を提供する「ディスクパフォ​​ーマンス」を確認しますが、このホストに追加されたのはXNUMX週間前であるため、XNUMXか月のビューでデータを相互に関連付けるために使用することはできません。

ディスクパフォ​​ーマンス情報のサブセットを見ると、ディスクは100％ビジーであり、読み取りと書き込みの両方の応答時間が短くなっています。 このアプリケーションでは、書き込みはメモリにバッファリングされるため、読み取り時間が重要ですが、読み取りが遅い場合は、エンドユーザーの応答に影響します。 週末にパフォーマンスが向上します。詳細については、以下をご覧ください。

5次に、特定のアプリパフォーマンスカウンターにドリルダウンします。
 
ここには明らかにいくつかのパフォーマンスの問題があります。 どうしたの？

さて、アプリケーションの応答時間は50番目に明らかに遅くなっていることがわかります（ただし、ひどいレベルではありません。非実稼働サーバーの場合、要求を処理するための9ミリ秒はまだ悪くありません）。10日と9日に奇妙なことに回復しました。その後、再び減速しました。 これはIO完了時間と相関関係がありますが、IO完了時間は実際にはディスクIOの合計とは相関関係がありません。 合計ディスクIOは一定（または増加）ですが、ディスクの応答時間は10日とXNUMX日の同じ負荷で改善され、その後再び遅くなりました…。 どうして？
このデモサーバーは、ESX上で実行される仮想マシンです。 ディスクIOごとの上位10の最もビジーな仮想マシンの概要グラフを見ると、デモサーバーのパフォーマンスが向上すると、そのホスト上の他のサーバーからのワークロードが少なくなることがわかりました。

それで謎が説明されました。 ESXホスト上のディスクは飽和状態でした。競合が少なくなると、特定のVMのパフォーマンスが向上しました。

それで、問題は何ですか、そして私はそれについて何をすべきですか？ LogicMonitorはどのように「問題の解決に役立ちますか？」

LogicMonitorは優れていますが、システムとアプリケーションを理解する必要性を否定することはできません。
提示されたLogicMonitor：

• ESXホストのディスク遅延が遅いことを警告します（上位10の仮想マシングラフは、どのVMがリソースを使用しているかを示します）。
• 調査中のVMのディスク読み取りが遅いことを警告します（この場合、パフォーマンスに影響を与えないため、書き込み時間アラートのしきい値が調整されました）。
• VMに多くのIO待機があったことを警告します。
• アプリケーションの応答時間が悪影響を受けていること、ワークロードが先月（ネットワークトラフィックとTomcat要求の両方）で100倍になったことを示す傾向。 そのディスクはXNUMX％で実行されていました。

したがって、アラートとグラフは問題を明確に特定したと思いますが、サーバーが稼働しているESXホストの現在の共有ディスクのパフォーマンスを考えると、サーバーは最大のワークロードで実行されています。システムの経験があれば、2 +2を使用できます。一緒。

ただし、包括的な監視とベースラインがない場合は、合計する数値すらわかりません。 （また、LogicMonitorの監視を行っていても、問題の根本原因を特定するのに問題がある場合は、サポートに連絡してください。喜んでサポートさせていただきます。）