【Continuous Profiling】Pyroscopeを試してみる

スポンサーリンク

はじめに

ローカルで Pyroscope を動かして、実際にプロファイリングしてみたいと思います。

Pyroscope

Pyroscope は、Continuous Profling を実現するための OSS になります。

Grafana Pyroscope documentation | Grafana Pyroscope documentation
Grafana Pyroscope documentation

Pyroscope を使うことで、パフォーマンスのボトルネックを探し出したり、CPU やメモリに関する問題を特定したりすることができます。

特徴としては、下記のようなことがあげられます。

  • エージェントの CPU オーバーヘッドが小さい
  • 水平スケール可能
  • タグによる分類
  • プロファイリング結果の比較や差分が確認できる

プロファイルを Pyroscope に送る方法は 下記の 2 つがあります。

  • Grafana Agent
    • コードの変更が不要
  • Pyroscope SDK
    • コードの変更が必要
    • カスタマイズが容易


公式ドキュメントより

サポートされている言語やセットアップの容易さ、カスタマイズしたいかを考慮して、どちらを利用するか選ぶことができます。

Sending profiles from your application | Grafana Pyroscope documentation
Sending profiles from your application Pyroscope is a continuous profiling database that allows you to analyze the performance of your applications. When sendin...

Continuous Profiling

Continuous Profiling は、意図しないタイミングで発生した問題や再現性のない問題でも Profiling できるように、継続的に Profiling をし続けることです。

What is continuous profiling?
Community post by Uchechukwu Obasi Coming from a background working as a frontend developer at Grafana I’m no stranger to open source performance monitoring. I ...

ローカルで試す

下記のサンプルを使って、ローカルで Pyroscope を試していきたいと思います。

https://github.com/grafana/pyroscope/tree/main/examples/java/rideshare

サンプルには 5 つのコンテナが含まれており、アプリケーションは 3 つの Region に分かれています。

  • Rideshare(us-east, eu-north, ap-south): アプリケーションのコンテナ
    • /car/bike/scooterの 3 つのエンドポイントを持つ
  • Load Generator: 負荷をかけるコンテナ
  • Pyroscope: Pyroscope 本体のコンテナ


公式ドキュメントより

Docker Compose で動かす

5 つのコンテナを Docker Compose を使って、起動します。

docker compose up -d

フレームグラフの確認

http://localhost:4040から Pyroscope の UI が確認できます。

アプリケーションの選択から "rideshare.java.push.app" -> "process_cpu:cpu" を選択すると、対象のアプリケーションの CPU のプロファイル結果を確認できます。

フレームグラフを確認すると、orderBikeorderScooterよりordeCarが圧倒的に CPU を使っていることが確認できます。

タグによる絞り込み

タグを設定していると、タグごとに結果をフィルタリングすることができます。

今回は、orderCarが怪しいので、"car"で絞り込んでおきます。

フレームグラフを比較する

他にも"region"というタグがあるので、それを使ってフレームグラフの比較をしてみます。

"region"タグを使って比較してみると、"eu-north"のみcheckDriverAvailabilityメソッドが CPU を多く使っていることがわかります。

差分をみても、"eu-north"以外ではcheckDriverAvailabilitymutexLockを呼び出していないことが確認できます。ちなみに、赤い部分は baseline と比較してリソースが増えた箇所、緑の部分は baseline と比較してリソースが削除されている箇所になります。

実際にコードを確認すると、"eu-north"のみmutexLockを呼び出しているのが確認できます。

https://github.com/grafana/pyroscope/blob/main/examples/java/rideshare/src/main/java/org/example/rideshare/OrderService.java#L43-L46

参考

タイトルとURLをコピーしました