JProfiler を使用して JVM 分析を開始する

 JVM をプロファイリングするには、JProfiler のプロファイリング エージェントを JVM にロードする必要があります。これは 2 つの異なる方法で実行できます。起動スクリプトで -agentpath VM パラメーターを指定する方法と、アタッチ API を使用してエージェントを既に実行中の JVM にロードする方法です。
JProfiler は両方のモードをサポートします。VM パラメータの追加はプロファイリングの推奨方法であり、JProfiler 内から JVM を起動するために統合ウィザード、IDE プラグイン、およびセッション構成によって使用されます。接続はローカルでも、SSH 経由でリモートでも行うことができます。

1. -agentpath VMパラメータ

プロファイリングされたエージェントをロードするための VM パラメータがどのように構成されているかを理解すると役立ちます。-agentpath は、JVMTI インターフェイスを使用する任意のタイプのネイティブ ライブラリをロードするために JVM によって提供される汎用 VM パラメータです。プロファイリング インターフェイス JVMTI はネイティブ インターフェイスであるため、プロファイリング エージェントはネイティブ ライブラリである必要があります。これは、明示的にサポートされているプラ​​ットフォームに対してのみコメントできることを意味します。32 ビットと 64 ビットの JVM には異なるネイティブ ライブラリも必要です。一方、Java エージェントは -javaagent-VM 引数を使用してロードされ、限られた機能セットにのみアクセスできます。
-agentpath: の後に、ネイティブ ライブラリの完全なパス名が追加されます。同等の引数 -agentlib があります。指定するのはプラットフォーム固有のライブラリ名のみですが、ライブラリがライブラリ パスに含まれていることを確認する必要があります。ライブラリへのパスの後に等号を追加し、カンマで区切ってオプションをエージェントに渡すことができます。たとえば、Linux では、パラメータ全体は次のようになります。

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

     最初の等号はパス名と引数を区切っており、2 番目の等号は引数 port=8849 の一部です。この汎用パラメータは、プロファイラ エージェントが JProfiler GUI からの接続をリッスンするポートを定義します。8849 は実際にはデフォルトのポートなので、そのパラメータを省略することもできます。ただし、同じマシン上で複数の JVM をプロファイリングする場合は、異なるポートを割り当てる必要があります。IDE プラグインとローカルで開始されたセッションでは、このポートが自動的に割り当てられます。統合ウィザードの場合は、ポートを明示的に選択する必要があります。
     2 番目のパラメーター nowait は、起動時に JVM をブロックしないようにプロファイラーに指示し、JProfiler GUI の接続を待機します。プロファイリング エージェントはプロファイリング設定をコマンド ライン引数としてではなく、JProfiler GUI または構成ファイルから受け取るため、起動時のブロックがデフォルトです。コマンド ライン引数は、プロファイリング エージェントをブートストラップし、起動方法とデバッグ フラグの渡し方を指示するためにのみ使用されます。
      デフォルトでは、JProfiler エージェントは通信ソケットを使用可能なすべてのネットワーク インターフェイスにバインドします。セキュリティ上の理由でこれが必要ない場合は、オプション address=[IP アドレス] を追加して、ローカル マシンからのリクエストのみをリッスンする特定のインターフェイスまたはループバックを選択できます。後者は、JProfiler UI または IDE 統合のために開始された JVM に自動的に追加されます。

2. ローカルで開始されたセッション

IDE の実行構成と同様に、ローカルで開始されたセッションを JProfiler で直接プロファイリングできます。クラスパス、メインクラス、作業ディレクトリ、VM パラメータと引数を指定すると、JProfiler がセッションを開始します。JProfiler に同梱されているすべてのデモ セッションは、ローカルで開始されるセッションです。

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

 ローカルで開始されたセッションは、メイン メニューから [セッション] -> [変換ウィザード] を呼び出し、変換ウィザードを使用してスタンドアロン セッションに変換できます。アプリケーション セッションをリモートに変換するには、起動スクリプトを作成し、Java 呼び出しに -agentpath VM パラメータを挿入するだけです。アプリケーション セッションをオフラインに変換すると、オフライン プロファイリング用の起動スクリプトが作成されます。これは、起動時に構成をロードすることを意味し、JProfiler GUI は必要ありません。アプリケーション セッションを再配布セッションに変換すると、同じ処理が行われますが、プロファイリング エージェントとプロファイルを含むディレクトリ jprofiler_dist がその隣に作成されるため、jprofiler がインストールされていない他のコンピュータに送信できるようになります。

分析されたアプリケーションを自分で開発する場合は、セッションを起動する代わりに IDE 統合の使用を検討してください。より便利になり、ソース コードのナビゲーションが向上します。アプリケーションを自分で開発していないが、起動スクリプトがすでにある場合は、リモート統合ウィザードの使用を検討してください。Java 呼び出しに追加する必要がある正確な VM パラメータがわかります。

3. 統合ウィザード

JProfiler の統合ウィザードは、追加の VM パラメータを含めるようにプログラム的に変更できる起動スクリプトまたは構成ファイルを使用して、多くのよく知られたサードパーティ コンテナと連携します。一部の製品では、引数または環境変数を介して渡される VM パラメーターを使用して起動スクリプトを生成できます。

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

 各統合ウィザードの最初のステップは、プロファイリングをローカル コンピュータで行うかリモート コンピュータで行うかを選択することです。ローカル マシンの場合、JProfiler はプラットフォーム、JProfiler がインストールされている場所、およびそのプロファイルの場所をすでに知っているため、提供する情報は少なくなります。

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

 ただし、プロファイルとプロファイル設定を指定することもでき、その方がはるかに効率的です。これは、構成の同期ステップ中に行われます。この場合の主な問題は、分析設定をローカルで編集するたびに、構成ファイルをリモート側と同期する必要があることです。最もエレガントな方法は、リモート アドレスのステップで SSH 経由でリモート マシンに接続することで、構成ファイルを SSH 経由で自動的に転送できます。

 統合ウィザードの最後に、セッションが作成され、分析が開始され、一般的なケースではない場合は、アプリケーション サーバーなどのサードパーティ製品が開始されます。

 外部起動スクリプトは、セッション設定ダイアログの「アプリケーション設定」タブにある「起動スクリプトの実行」および「停止スクリプトの実行」オプションで処理され、「URLを使用してブラウザを開く」チェックボックスをチェックすることでURLが表示されます。ここで、リモート マシンのアドレスを変更したり、同期オプションを構成したりすることもできます。

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

 リモート評価セッションの開始時にエラーが発生した場合は、問題を解決するための手順のリストについては、トラブルシューティング ガイドを参照してください。

4.IDEの統合

アプリケーションを評価する最も便利な方法は、IDE 統合を使用することです。通常、開発中に IDE からアプリケーションを起動する場合、IDE には必要な情報がすべてすでに含まれており、JProfiler プラグインはプロファイリング用の VM パラメータを追加するだけで、必要に応じて JProfiler を起動し、プロファイリングされた JVM を JProfiler メイン ウィンドウに接続できます。
すべての IDE 統合は、JProfiler インストールの統合ディレクトリに含まれています。原則として、このディレクトリ内のアーカイブは、それぞれの IDE のプラグイン インストール メカニズムを介して手動でインストールできます。ただし、IDE 統合をインストールするための推奨される方法は、メイン メニューから [セッション] -> [IDE 統合] を起動することです。 

 

IDE のプロファイリング セッションは、JProfilerGUI から開始できないため、JProfiler で独自のセッション エントリを取得しません。IDE の設定に応じて、分析設定はプロジェクトごとまたは実行ごとの構成ベースで保持されます。
IDE に接続すると、JProfiler はツールバーにウィンドウ スイッチャーを表示し、IDE の関連するウィンドウに簡単に戻ることができます。すべての ShowSource アクションは、JProfiler の組み込みソース ビューアではなく、IDE にソースを直接表示するようになりました。

五、追加モード

JVM のプロファイリングを行うかどうかを事前に決定する必要はありません。JProfiler の追加機能を使用すると、実行中の JVM を選択し、プロファイリング エージェントを動的にロードできます。接続モードは便利ですが、注意すべき欠点がいくつかあります。

  • 実行中の JVM のリストからプロファイリングする JVM を決定する必要があります。多くの JVM が同じマシン上で実行されている場合、これは難しい場合があります。
  • 挿入を追加するには多くのクラスを再定義する必要がある可能性があるため、追加のオーバーヘッドが発生します。
  • JProfiler の一部の機能は追加モードでは使用できません。これは主に、JVMTI の一部の機能は JVM の初期化時にのみ有効にすることができ、JVM ライフサイクルの後の段階では使用できないためです。
  • 一部の機能は、すべてのクラスの大部分に挿入する必要があります。クラスがロードされるときにインスツルメンテーションを行うのは低コストですが、後でクラスがロードされるときにインスツルメンテーションを追加するのは低コストです。アタッチ モードを使用する場合、これらの機能はデフォルトで無効になります。
  • OpenJDK JVM、バージョン 6 以降の Oracle JVM、最新の OpenJ9 JVM (8u281+、11.0.11+、または Java 17+)、またはそのようなバージョンに基づく IBM JVM はすべて、追加機能をサポートしています。VM パラメーター -XX:+PerfDisableSharedMem および -XX:+DisableAttachMechanism は JVM に指定できません。
  • JProfiler のスタート センターの [クイック アタッチ] タブには、プロファイリング可能なすべての JVM がリストされます。リスト項目の背景色は、プロファイリング エージェントがロードされているか、JProfiler GUI が現在接続されているか、またはオフライン プロファイリングが構成されているかを示します。
  • 分析セッションを開始するときに、分析設定を [セッション設定] ダイアログで構成できます。同じプロセスを繰り返し構成する場合、同じ構成を何度も再入力する必要がないため、高速接続機能を使用して作成されたセッションを閉じるときに永続セッションを保存できます。次回このプロセスを測定する場合は、[クイック接続] タブではなく、[セッションを開く] タブから保存されたセッションを開始してください。実行中の JVM を選択する必要がありますが、プロファイリング設定は以前に構成したものと同じです。 

 

 6. ローカルサービスに接続する

JVM のアタッチ API では、呼び出しプロセスがアタッチ先のプロセスと同じユーザーとして実行する必要があるため、JProfiler によって表示される JVM のリストは現在のユーザーに限定されます。さまざまなユーザーによって開始されるプロセスのほとんどはサービスです。サービスに接続する方法は、Windows、Linux、Unix ベースのプラットフォームによって異なります。
Windows では、[エクストラ] ダイアログに [サービスの表示] ボタンがあり、ローカルで実行されているすべてのサービスが一覧表示されます。JProfiler は、どのユーザーとして実行しているかに関係なく、これらのプロセスに接続できるようにブリッジング実行可能ファイルを開始します。

 Linux では、JProfiler は、ほとんどの Linux ディストリビューションの一部である PolicyKit を介して UI で直接ユーザーを切り替えることをサポートしています。追加のダイアログで「ユーザーの切り替え」をクリックすると、別のユーザー名を入力し、システムパスワードダイアログを使用して認証できます。

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

sudo -u userName jpenable

su の場合、必要なコマンド ラインは次のとおりです。

su userName -c jpenable

jpenable を使用すると、JVM を選択し、プロファイリング エージェントがリッスンしているポートを通知できます。起動センターの [クイック接続] タブで、[別のコンピュータ上] オプションを選択し、ローカルホストへの直接接続と指定されたプロファイルのポートを構成できます。

7. リモート コンピューター上の JVM に接続します。

最も要求の厳しいプロファイリング設定はリモート プロファイリングです。JProfiler GUI はローカル マシン上で実行され、プロファイリング JVM は別のマシン上で実行されます。-agentpath VM パラメーターがプロファイル JVM に渡されるセットアップの場合、JProfiler をリモート マシンにインストールし、ローカル マシンでリモート セッションをセットアップする必要があります。JProfiler のリモート接続機能を使用すると、そのような変更は必要なく、リモート コンピューターにログインするために必要なのは SSH 資格情報のみです。
SSH 接続により、JProfiler はヘルプ トピック「JProfiler のインストール」で説明されているエージェント パッケージをアップロードし、付属のコマンド ライン ツールをリモート マシン上で実行できるようになります。ローカル マシンに SSH をセットアップする必要はありません。JProfiler が付属しています。最も単純なセットアップでは、ホスト、ユーザー名、認証を定義するだけで済みます。
SSH 接続を使用すると、JProfiler は実行中の JVM を自動的に検出したり、プロファイリング エージェントがすでにリッスンしている特定のポートに接続したりできます。後者の場合、jpenable または jpintegrate を使用して、ベンチマーク用の特別な JVM を準備できます。その後、構成された分析ポートに直接接続するように SSH リモート接続を構成できます。

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

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

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

 

おすすめ

転載: blog.csdn.net/leesinbad/article/details/132124221