JProfiler ヘルプ

JVMのプロファイリング

JVMをプロファイルするには、JProfilerのプロファイリングエージェントをJVMにロードする必要があります。これには2つの方法があります。 起動スクリプトで-agentpath VMパラメータを指定するか、attach APIを使用して既に実行中のJVMにエージェントをロードする方法です。

JProfilerは両方のモードをサポートしています。VMパラメータの追加は推奨されるプロファイリング方法であり、統合ウィザード、IDEプラグイン、およびJProfiler内からJVMを起動するセッション設定で使用されます。 attachはローカルでもSSH経由のリモートでも機能します。

-agentpath VMパラメータ

プロファイリングエージェントをロードするVMパラメータがどのように構成されているかを理解しておくと役立ちます。-agentpathは、JVMTIインターフェースを使用するあらゆる種類のネイティブライブラリをロードするためにJVMが提供する汎用VMパラメータです。 プロファイリングインターフェースであるJVMTIはネイティブインターフェースであるため、プロファイリングエージェントはネイティブライブラリである必要があります。これは、 明示的にサポートされているプラットフォーム上でのみプロファイルできることを意味します。 また、32ビットと64ビットのJVMでは異なるネイティブライブラリが必要です。 一方、Javaエージェントは-javaagent VMパラメータでロードされ、アクセスできる機能のセットは限定されています。

-agentpath:の後には、ネイティブライブラリへのフルパス名が付加されます。同等のパラメータとしてプラットフォーム固有のライブラリ名のみを指定する-agentlib:もありますが、その場合はライブラリがライブラリパスに含まれていることを確認する必要があります。ライブラリへのパスの後には、等号(=)を追加して、カンマで区切ったオプションをエージェントに渡すことができます。たとえばLinuxでは、パラメータ全体は次のようになります。

-agentpath:/opt/jprofiler16/bin/linux-x64/libjprofilerti.so=port=8849,nowait

最初の等号はパス名とパラメータを区切り、2番目の等号はパラメータport=8849の一部です。この一般的なパラメータは、プロファイリングエージェントがJProfiler GUIからの接続をリッスンするポートを定義します。8849はデフォルトのポートであるため、このパラメータは省略することも可能です。 ただし、同じマシン上で複数のJVMをプロファイルする場合は、異なるポートを割り当てる必要があります。 IDEプラグインおよびローカルで起動されたセッションではこのポートが自動的に割り当てられますが、統合ウィザードではポートを明示的に選択する必要があります。

2番目のパラメータnowaitは、起動時にJVMをブロックしてJProfiler GUIが接続するのを待機しないようプロファイリングエージェントに指示します。プロファイリングエージェントはプロファイリング設定をコマンドラインパラメータからではなく、JProfiler GUIまたは設定ファイルから受け取るため、起動時のブロックがデフォルトになっています。コマンドラインパラメータは、プロファイリングエージェントのブートストラップ、起動方法の指示、およびデバッグフラグの受け渡しにのみ使用されます。

状況によっては、起動時にプロファイリング設定を行うことが必要となり、これを実現するためにいくつかの手動作業が必要になる場合があります。

デフォルトでは、JProfilerエージェントは通信socketをループバックインターフェースにバインドします。特定のインターフェースを選択するためにオプションaddress=[IP address]を追加したり、利用可能なすべてのネットワークインターフェースに通信socketをバインドするためにaddress=0.0.0.0を追加したりできます。これは、Dockerコンテナからプロファイリングポートを公開する場合などに必要となります。

ローカルで起動されたセッション

IDEの「実行構成」と同様に、JProfilerで直接ローカル起動セッションを設定できます。クラスパス、メインクラス、作業ディレクトリ、VMパラメータ、引数を指定すると、JProfilerがセッションを起動します。JProfilerに付属しているすべてのデモセッションは、ローカルで起動されるセッションです。

特別な起動モードとして「Web Start」があり、JNLPファイルのURLを選択すると、JProfilerがそれをプロファイルするためのJVMを起動します。この機能はOpenWebStartをサポートしていますが、Java 9より前のOracle JREのレガシーWebStartはサポートされていません。

ローカルで起動されたセッションは、メインメニューからSession→Conversion Wizardsを呼び出すことで、変換ウィザードを使用してスタンドアロンセッションに変換できます。Convert Application Session to Remoteは、単に起動スクリプトを作成し、Java呼び出しに-agentpath VMパラメータを挿入します。 Convert Application Session to Offlineはオフラインプロファイリング用の起動スクリプトを作成します。これは、設定が起動時にロードされ、JProfiler GUIが不要であることを意味します。 Convert Application Session to Redistributed Sessionも同様の処理を行いますが、プロファイリングエージェントと設定ファイルを含むディレクトリjprofiler_redistを隣に作成するため、JProfilerがインストールされていない別のマシンに配布できます。

プロファイルされたアプリケーションを自身で開発している場合は、起動されたセッションの代わりにIDE統合を使用することを検討してください。その方が便利であり、ソースコードのナビゲーションも向上します。自身でアプリケーションを開発しておらず、すでに起動スクリプトがある場合は、リモート統合ウィザードの使用を検討してください。Javaの呼び出しに追加する必要がある正確なVMパラメータが提示されます。

統合ウィザード

JProfilerの統合ウィザードは、追加のVMパラメータを含めるようにプログラムで変更できる起動スクリプトや設定ファイルを持つ、多くの有名なサードパーティコンテナに対応しています。 一部の製品では、VMパラメータを引数や環境変数を介して渡す起動スクリプトを生成できます。

いずれの場合も、サードパーティ製品から特定のファイルを指定する必要があり、これによりJProfilerが変更を行うために必要なコンテキストを取得できます。汎用ウィザードの一部は、プロファイリングを有効にするために必要な手順を指示するだけです。

各統合ウィザードの最初のステップは、ローカルマシンでプロファイルするか、リモートマシンでプロファイルするかの選択です。ローカルマシンの場合、JProfilerはプラットフォーム、JProfilerがインストールされている場所、およびその設定ファイルがどこにあるかをすでに把握しているため、指定する情報は少なくて済みます。

重要な決定事項は、前述した「起動モード」です。デフォルトでは、プロファイリング設定は起動時にJProfiler UIから送信されますが、JVMを即座に開始させるようにプロファイリングエージェントに指示することもできます。後者の場合、JProfiler GUIが接続された時点でプロファイリング設定を適用できます。

ただし、プロファイリング設定を含む設定ファイルを指定することもでき、その方がはるかに効率的です。 これはConfig synchronizationステップで行われます。この場合の主な問題は、ローカルでプロファイリング設定を編集するたびに、設定ファイルをリモート側と同期させる必要があることです。最も洗練された方法は、Remote addressステップでSSH経由でリモートマシンに接続することです。これにより、設定ファイルをSSH経由で自動的に転送できます。

統合ウィザードの最後には、プロファイリングを開始し、汎用でないケースではアプリケーションサーバーなどのサードパーティ製品も起動するセッションが作成されます。

外部起動スクリプトは、セッション設定ダイアログのApplication settingsタブにあるExecute start commandおよびExecute stop commandオプションによって処理され、Open browser with URLチェックボックスを選択することでURLを表示できます。ここは、リモートマシンのアドレスや設定の同期オプションを変更する場所でもあります。

統合ウィザードはすべて、プロファイルされたJVMがリモートマシン上で実行されているケースを処理します。ただし、設定ファイルや起動スクリプトを変更する必要がある場合は、それをローカルマシンにコピーし、変更されたバージョンをリモートマシンに転送し直す必要があります。リモートマシン上で直接コマンドラインツール jpintegrateを実行し、その場で変更を行わせる方が便利な場合があります。 jpintegrateにはJProfilerの完全なインストールが必要であり、JProfiler GUIと同じJRE要件があります。

リモートプロファイリングセッションの開始中にエラーが発生した場合は、問題を解決するために実行できる手順のチェックリストについてトラブルシューティングガイドを参照してください。

IDE統合

アプリケーションをプロファイルする最も便利な方法は、IDE統合を利用することです。開発中に通常IDEからアプリケーションを起動している場合、IDEにはすでに必要なすべての情報が含まれているため、JProfilerプラグインはプロファイリング用のVMパラメータを追加し、必要に応じてJProfilerを起動して、プロファイルされたJVMをJProfilerのメインウィンドウに接続するだけで済みます。

すべてのIDE統合は、JProfilerインストール環境のintegrationsディレクトリに含まれています。 基本的には、それぞれのIDEのプラグインインストール機能を使用して、そのディレクトリ内のアーカイブを手動でインストールできます。ただし、IDE統合をインストールする推奨の方法は、メインメニューからSession→IDE integrationsを呼び出すことです。

IDEからのプロファイリングセッションは、JProfiler GUIから起動できないため、JProfiler内に独自のセッションエントリを持ちません。プロファイリング設定は、IDEの設定に応じて、プロジェクトごとまたは実行構成ごとに永続化されます。

IDEに接続されている場合、JProfilerのツールバーにはウィンドウ切替ボタンが表示され、IDE内の関連ウィンドウに簡単に戻ることができます。すべてのShow Sourceアクションは、JProfilerの内蔵ソースビューアーではなく、IDE内で直接ソースを表示するようになります。

IDE統合については、以降の章で詳しく説明します。

AIエージェント用MCPサーバー

JProfilerには、Claude Code、Antigravity、JunieなどのAIコーディングエージェントがJProfilerのプロファイリングおよび分析機能を使用できるようにするMCPサーバーが含まれています。AIエージェントは、Javaプロセスの開始とプロファイル、ローカルで実行中のJVMやDockerコンテナ内のJVMへのattach、ヒープダンプの作成、既存のスナップショットの分析を行うことができます。MCP統合は、メインメニューのSession→AI Agent Integrationsから設定します。

Attachモード

JVMをプロファイルすることを事前に決めておく必要は必ずしもありません。JProfilerのattach機能を使用すると、実行中のJVMを選択して、その場でプロファイリングエージェントをロードできます。 attachモードは便利ですが、注意すべきいくつかの欠点があります。

  • 実行中のJVMのリストからプロファイルするJVMを特定する必要があります。同じマシン上で多数のJVMが実行されている場合、これは時に困難になることがあります。
  • インスツルメンテーションを追加するために非常に多くのクラスを再定義しなければならない可能性があるため、追加のオーバーヘッドが発生します。
  • JProfilerの一部の機能はattachモードでは利用できません。これは主に、JVMTIの機能の一部がJVMの初期化時にしか有効化できず、JVMのライフサイクルの後半フェーズでは利用できないためです。
  • 一部の機能では、すべてのクラスの大部分でインスツルメンテーションが必要です。クラスのロード中にインスツルメンテーションを行うのは負荷が低いですが、クラスがすでにロードされた後からインスツルメンテーションを追加する負荷は高くなります。このような機能は、attachモードを使用する場合、デフォルトで無効化されます。
  • attach機能は、OpenJDK JVM、バージョン6以上のOracle JVM、最近のOpenJ9 JVM(8u281+、11.0.11+、またはJava 17+)、あるいはそのようなリリースに基づくIBM JVMでサポートされています。JVMにはVMパラメータ-XX:+PerfDisableSharedMemおよび-XX:+DisableAttachMechanismが指定されていてはなりません。

JProfilerのスタートセンターにあるQuick Attachタブには、プロファイル可能なすべてのJVMが一覧表示されます。リストエントリの背景色は、プロファイリングエージェントがすでにロードされているか、JProfiler GUIが現在接続されているか、またはオフラインプロファイリングが設定されているかを示します。

プロファイリングセッションを開始する際、セッション設定ダイアログでプロファイリング設定を構成できます。同じプロセスを繰り返しプロファイルする場合、同じ設定を何度も再入力したくはないため、クイックアタッチ機能で作成されたセッションを閉じるときに永続セッションを保存できます。次回このプロセスをプロファイルする際は、Quick Attachタブの代わりにStart Sessionタブから保存したセッションを開始します。実行中のJVMを選択する必要は依然としてありますが、プロファイリング設定は以前に構成したものと同じになります。

ローカルサービスへのattach

JVMのattach APIでは、呼び出し元のプロセスがattach先プロセスと同じユーザーとして実行されている必要があるため、JProfilerに表示されるJVMのリストは現在のユーザーのものに限定されます。異なるユーザーによって起動されたプロセスは、ほとんどがサービスです。サービスにattachする方法は、Windows、Linux、Unixベースのプラットフォームで異なります。

Windowsでは、attachダイアログにローカルで実行中のすべてのサービスを一覧表示するShow Servicesボタンがあります。JProfilerはブリッジ実行ファイルを起動し、それらのプロセスがどのユーザーで実行されているかに関係なくattachできるようにします。

Linuxでは、JProfilerはほとんどのLinuxディストリビューションに含まれているPolicyKitを介して、UI内で直接ユーザーを切り替えることをサポートしています。attachダイアログでSwitch Userをクリックすることで、別のユーザー名を入力し、システムのパスワードダイアログで認証できます。

macOSを含むUnixベースのプラットフォームでは、UnixのバリアントやLinuxディストリビューションに応じて、 suまたは sudoを使用してコマンドラインツール jpenableを別のユーザーとして実行できます。macOSやUbuntuなどのDebianベースのLinuxディストリビューションでは、 sudoが使用されます。

sudoの場合、以下を呼び出します。

sudo -u userName jpenable
suの場合、必要なコマンドラインは次のようになります。
su userName -c jpenable

jpenableによってJVMを選択でき、プロファイリングエージェントがリッスンしているポートが提示されます。その後、JProfiler UIからのローカルセッション、またはjpenableによって提示されたポートに直接接続するSSH接続のいずれかで接続できます。

リモートマシン上のJVMへのattach

プロファイリングにおいて最も高度なセットアップは、リモートプロファイリングです。JProfiler GUIがローカルマシン上で実行され、プロファイルされたJVMが別のマシン上で実行されます。プロファイルされたJVMに-agentpath VMパラメータを渡すセットアップでは、リモートマシンにJProfilerをインストールし、ローカルマシンでリモートセッションをセットアップする必要があります。JProfilerのリモートattach機能を使用すれば、そのような変更は一切不要です。リモートマシンにログインするためのSSHクレデンシャルを用意するだけです。

SSH接続により、JProfilerは「JProfilerのインストール」のヘルプトピックで説明されているエージェントパッケージをアップロードし、リモートマシン上で含まれているコマンドラインツールを実行できるようになります。ローカルマシンにSSHをセットアップする必要はありません。JProfilerには独自の実装が付属しています。最も簡単なセットアップでは、ホスト、ユーザー名、認証を定義するだけです。

SSH接続を使用すると、JProfilerは実行中のJVMの自動検出を実行したり、プロファイリングエージェントがすでにリッスンしている特定のポートに接続したりできます。後者の場合、前述のようにリモートマシン上で jpenableまたは jpintegrateを使用して、特定のJVMをプロファイリング用に準備できます。その後、設定されたプロファイリングポートに直接接続するようにSSHリモートattachを設定できます。

自動検出では、SSHログインユーザーとして起動されたリモートマシン上のすべてのJVMが一覧表示されます。ほとんどの場合、これはプロファイルしたいサービスを起動したユーザーとは異なります。サービスを起動するユーザーは通常SSH接続が許可されていないため、JProfilerには sudoまたは suを使用してそのユーザーに切り替えることができるSwitch Userハイパーリンクが追加されています。

複雑なネットワークトポロジでは、リモートマシンに直接接続できない場合があります。その場合、GUIでマルチホップSSHトンネルを使用して接続するようJProfilerに指示できます。SSHトンネルの終点で、通常は「127.0.0.1」への直接ネットワーク接続を1つ確立できます。

他の認証メカニズムについては、OpenSSHトンネルモードを使用できます。OpenSSHの実行ファイルを使用するときにコマンドラインに入力するのと同様に、ホスト名を入力します。これは、OpenSSH設定ファイルで構成されたエイリアスでも構いません。ホスト名のほかに、ポートとユーザー名をオプションで指定できます。Windowsでは、Microsoftによる内蔵のOpenSSHクライアントのみがサポートされています。

SSHオプションのテキストフィールドには、コマンドラインで指定するようなOpenSSH実行ファイルへの任意の追加引数を指定できます。これは、たとえばAWS Session Manager経由でSSH接続をトンネリングする方法など、チュートリアルに記載された手順に従っている場合に特に役立ちます。

HPROFスナップショットは、SSHログインユーザーで起動されたJVMに対してのみ取得できます。これは、HPROFスナップショットがJVMを起動したユーザーのアクセス権限で書き込まれる中間ファイルを必要とするためです。セキュリティ上の理由から、ダウンロードのためにファイル権限をSSHログインユーザーに移譲することはできません。完全なプロファイリングセッションにはこのような制限はありません。

Dockerコンテナで実行中のJVMへのattach

Dockerコンテナには通常SSHサーバーがインストールされておらず、Dockerコンテナ内でjpenableを使用することはできますが、Dockerfileで指定していない限りプロファイリングポートには外部からアクセスできません。

JProfilerでは、クイックアタッチダイアログでDockerコンテナを選択することにより、WindowsまたはmacOSのローカルのDocker Desktop環境で実行されているJVMにattachできます。デフォルトでは、JProfilerは docker実行ファイルへのパスを自動的に検出します。あるいは、一般設定ダイアログの「External Programs」タブで設定することもできます。

コンテナを選択すると、Dockerコンテナ内で実行されているすべてのJVMが表示されます。JVMを選択すると、JProfilerはDockerコマンドを使用して選択したコンテナにプロファイリングエージェントを自動的にインストールし、JVMのプロファイリングの準備を行い、プロファイリングプロトコルを外部にトンネリングします。

リモートのDocker環境の場合は、SSHリモートattach機能を使用してリモートマシン上のDockerコンテナを選択できます。ログインユーザーがdockerグループに属していない場合は、前述のようにまずユーザーを切り替えることができます。

リモートattachダイアログのSelect Containerハイパーリンクを使用すると、実行中のDockerコンテナを選択し、その中で実行されているすべてのJVMを表示できます。

Kubernetesクラスターで実行中のJVMへのattach

Kubernetesクラスター上で実行されているJVMをプロファイルするために、JProfilerはPodやコンテナの検出、コンテナへの接続、そのJVMの一覧表示、そして最終的に選択したJVMへの接続の両方に kubectlコマンドラインツールを使用します。

kubectlコマンドラインツールは、ローカルコンピュータ上にある場合もあれば、SSHアクセス権を持つリモートマシン上にある場合もあります。JProfilerは両方のシナリオを直接サポートしています。ローカル環境の場合、JProfilerは kubectlへのパスを自動的に検出しようとしますが、一般設定ダイアログの「External Programs」タブで明示的なパスを設定することもできます。

JProfilerは、検出されたすべてのコンテナを3つのレベルを持つツリーに一覧表示します。最上位には、検出されたPodを含む子ノードを保持するネームスペースノードがあります。リーフノードはコンテナ自体であり、実行中のJVMの選択に進むにはそのうちの1つを選択する必要があります。

Kubernetesクラスターに接続できるようにするために、 kubectlは認証用の追加のコマンドラインオプションを必要とする場合があります。これらのオプションは、コンテナ選択ダイアログの上部に入力できます。これらのオプションは機密情報である可能性があるため、再起動後も記憶するチェックボックスを明示的に選択した場合にのみディスクに保存されます。このチェックボックスの選択を解除すると、以前に保存された情報が直ちに消去されます。

実行中のJVMの表示名を設定する

JVM選択テーブルにおいて、表示されるプロセス名はプロファイルされたJVMのメインクラスとその引数です。exe4jまたはinstall4jによって生成されたランチャーの場合、実行ファイル名が表示されます。

表示名を自身で設定したい場合(たとえば、同じメインクラスを持つ複数のプロセスが存在し、それ以外では区別できない場合など)、VMパラメータ-Djprofiler.displayName=[name]を設定できます。名前にスペースが含まれている場合は、単一引用符(シングルクォート)を使用して-Djprofiler.displayName='My name with spaces'とし、必要に応じてVMパラメータ全体を二重引用符(ダブルクォート)で囲みます。-Djprofiler.displayNameに加えて、JProfilerは-Dvisualvm.display.nameも認識します。