JProfiler ヘルプ

JVMのプロファイリング

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

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

-agentpath VMパラメーター

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

-agentpath:の後に、ネイティブlibraryへのフルパス名が追加されます。同等のパラメーター-agentlib:では プラットフォーム固有のlibrary名のみを指定しますが、その場合はlibraryがlibrary パスに含まれていることを確認する必要があります。 libraryへのパスの後に等号を追加してエージェントにオプションをカンマ区切りで渡すことができます。 例えば、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=0.0.0.0を使用して通信socketをすべての利用可能なネットワークインターフェースにバインドできます。 これは、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 scriptExecute stop scriptオプションで処理され、 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 server

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

attach mode

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

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

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のバリアントまたはディストリビューションに応じて、 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は別のマシンで実行されます。-agentpath VMパラメーターをプロファイルされたJVMに渡すセットアップでは、 リモートマシンにJProfilerをインストールし、ローカルマシンにリモートセッションを設定する必要があります。 JProfilerのリモートattach機能を使用すれば、そのような変更は不要です。 リモートマシンにログインするためのSSH認証情報があれば十分です。

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

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

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

複雑なネットワークトポロジーでは、リモートマシンに直接接続できない場合があります。 その場合、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 tools」タブで設定することもできます。

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

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

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

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

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

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

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

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

実行中のJVMの表示名の設定

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

表示名を自分で設定したい場合、例えば同じメインクラスを持つ複数のプロセスがあり、 そうでなければ区別できない場合は、VMパラメーター-Djprofiler.displayName=[name]を設定できます。 名前にスペースが含まれる場合はシングルクォートを使用してください: -Djprofiler.displayName='My name with spaces' 必要に応じてVMパラメーター全体をダブルクォートで囲んでください。 -Djprofiler.displayNameに加えて、JProfilerは -Dvisualvm.display.nameも認識します。