【Continuous Profiling】Pyroscopeを試してみる

2023.11.25
2024.03.24
パフォーマンスチューニング
Pyroscope

はじめに

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

Pyroscope

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

Grafana Pyroscope |  Grafana Pyroscope documentation

Grafana Pyroscope | Grafana Pyroscope documentation

Grafana Pyroscope is an open source software project for aggregating continuous profiling data.

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

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

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

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

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

公式ドキュメントより

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

Configure the client to send profiles |  Grafana Pyroscope documentation

Configure the client to send profiles | Grafana Pyroscope documentation

Learn how to configure the client to send profiles from your application.

Continuous Profiling

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

What is continuous 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 was part of a team that was responsible…

ローカルで試す

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

unknown link

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

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

公式ドキュメントより

Docker Compose で動かす

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

1docker compose up -d

フレームグラフの確認

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

アプリケーションの選択から "rideshare.java.push.app" -> "process_cpu

" を選択すると、対象のアプリケーションの CPU のプロファイル結果を確認できます。

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

タグによる絞り込み

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

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

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

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

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

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

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

unknown link

参考

Support

\ この記事が役に立ったと思ったら、サポートお願いします! /

buy me a coffee
Share

Profile

author

Masa

都内のIT企業で働くエンジニア
自分が学んだことをブログでわかりやすく発信していきながらスキルアップを目指していきます!

buy me a coffee