Docs » Splunk APMのAlwaysOn Profilingの概要 » Splunk AlwaysOn Profilingを使用したアプリケーションとサービスの監視シナリオ » シナリオ：SashaがAlwaysOn Profilingを使用してパフォーマンスの問題を検出する

シナリオ：SashaがAlwaysOn Profilingを使用してパフォーマンスの問題を検出する 🔗

BirdlympicsはButtercup Gamesが発売したJavaゲームです。各ラウンドの最初に、プレイヤーは3人のレーサーを選びます。各レースの後、Birdlympicsは結果をPostgreSQLデータベースに保存し、それぞれの鳥の統計情報をフィードします。次のアニメーションは、Birdlympicsゲームの動作を示しています：

架空のゲーム「Birdlympics」内のラウンド

Buttercup GamesのマーケティングチームがBirdlympicsのプロモーションキャンペーンを開始した日、開発者リーダーのSashaは、ゲームをホストしているマシンのCPU消費量が高いというアラートを受け取りました。SashaはSplunk Infrastructure Monitoringでホストの詳細情報を開き、異常に高いCPU消費量に気づきます：

Birdlympicsのサーバーのホストビュー。CPUの消費量が多くなっています。

Sashaは、JVMプロセスがCPU負荷の大部分を占めていることに気づきました。パフォーマンスの問題の原因は、Birdlympicsのコードにあるかもしれません。Splunk APMでBirdlympicsのサービスマップを調査し、どの鳥が最も速いかを計算するコントローラーのレイテンシが高いことに気づきました：

Splunk APMの高レイテンシタグ。

Sashaは、AlwaysOn Profilingを有効にしてSplunk Javaエージェントを使用してゲームをインストルメントしたため、Splunk APMを使用して問題をトラブルシューティングし、ボトルネックを修正します。以下の手順を踏みます：

  1. 遅いスパンとそのスタックトレースを調査する

  2. フレームグラフを使用して集計データを参照する

  3. コードにバグやボトルネックがないかチェックする

  4. コードを修正し、再度パフォーマンスを測定する

遅いスパンとそのスタックトレースを調査する 🔗

何が高負荷の原因なのかを理解するために、SashaはSplunk APMを開き、「Birdlympics」環境を選択し、Traces を選択しました。利用可能なトレースをフィルタリングして、最小継続時間が1秒になるようにします。ほぼすべての結果に stats/races/fastest の操作が含まれています：

Birdlympicsアプリケーションのトレースリスト。継続時間が1秒以上のものだけを表示するようにフィルタリングされています。

Sashaは最も遅いトレースを開いてスパンを調査します。多くのスパンではコールスタックが使用でき、Birdlympicsがその時点でどの関数をどの順序で呼び出したかのを示しています。Sashaはスパンの1つを展開し、スタックトレースをスクロールして、ボトルネックの背後にあるコードを特定します：

ゲーム内の遅いスパンのスタックトレース。ゲームクラスのプレフィックスがハイライトされています。

Sashaは、データベースに接続するいくつかのクラスを特定します。Span Performance ビューを見ると、StatsController.fastestRace 関数が処理負荷の84%を占めていることが分かります。fastestRace 関数は、レース終了時にどの出場者がより速かったかを計算し、データベース呼び出しを実行します：

トレースの[スパンパフォーマンス]タブ。総ワークロードに寄与している操作が表示されています。

フレームグラフを使用して集計データを参照する 🔗

スタックトレースによってSashaは正しい道をたどっていますが、さらに多くの証拠があれば、最適化すべき点を確認することができます。Sashaは、スパンビューから View in AlwaysOn Profiler を選択します。フレームグラフがアプリケーショ ンコードのみをハイライト表示するようにビューをフィルタリングし、スクロールしてスタックの分析を続けます：

フレームグラフの結果のフィルタリングと、ズームイン。

パフォーマンスに影響を与えているアプリケーションコードの大部分は、BirdDao.java ファイルの69行目から来ています。関数が費やした時間をまとめた、スタックのセルフタイムのフレームは、予想より高くなっています：

トレースの[スパンパフォーマンス]タブ。総ワークロードに寄与している操作が表示されています。

コードにバグやボトルネックがないかチェックする 🔗

Splunk APMとそのフレームグラフから収集した情報を使って、Sashaはコードエディターを開き、BirdDao.java をチェックします。問題はかなり些細なものであることが分かりました。69行目の非効率的なループがデータベースクエリの増加を引き起こしており、それが高負荷時のCPU消費を引き起こしているのです：

Birdlympicsの最善ではないコード。

コードを修正し、再度パフォーマンスを測定する 🔗

コードを改善し、アプリケーションを再起動すると、パフォーマンスへの影響はほとんどなくなり、フレームグラフでは、ボトルネックの原因となっていた関数のスタックフレームがかなり狭くなっていることがわかります。Sashaはこの朗報をマーケティングチームに伝え、マーケティングキャンペーンを実施できると保証しました。

次の画像は、Splunk Infrastructure Monitoringのホストナビゲーターを示すものです。ハイライトされた四角は、このゲームサーバーをホストしている仮想マシンです：

Infrastructure Monitoringで、ホストのCPU消費量の表示は低くなっています。

まとめ 🔗

Sashaは、Splunk Infrastructure Monitoring、Splunk APM、AlwaysOn Profiling を組み合わせて使用することで、Birdlympicsのゲームにおける2つの重大なパフォーマンス問題を迅速に特定して修正し、リソースの拡張の必要性を回避しながらマーケティングキャンペーンを継続することができました。

SashaがAlwaysOn Profilingを使ってメモリの問題を特定する方法については、シナリオ：SashaがAlwaysOn Profilingを使用してメモリ使用量を分析する を参照してください。

さらに詳しく 🔗

このページは 2023年05月26日 に最終更新されました。