問題タブ [java-mission-control]

同様の質問がここで尋ねられました。

指示に従って構築した JMC 7.1.0 を使用して、Open JDK 11.0.2 アプリケーションをプロファイリングしています。

アプリケーションは約 3 つのコアを使用しており、過剰な gc はなく、スレッドが実際に CPU を使用するネイティブ メソッド呼び出しを行っている時間のごく一部です。

デフォルトのメソッドのサンプリング間隔である 10ms を使用しています。以下を使用して、セーフポイント外のデバッグ メタ データを有効にしました。

-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints

採取されたサンプルの数は、私が予想するよりもはるかに少ないです。各サンプリング ポイントで非ネイティブ コードを実行している CPU スレッドに 1 があると保守的に仮定すると、100 サンプル/秒が予想されます。それでも、1 秒あたり 1 サンプルしか表示されません。

マシン自体は通常 50% アイドル状態であるため、サンプリング スレッドが枯渇することはありません。

サンプル数が少ない原因は何ですか?

テスト中の Java プログラムに次の CLI オプションを指定して、起動時に JFR を開始しています。

テストの実行には 90 秒かかります。

Java Mission Control で JFR ダンプを開くと、JMC の [呼び出しツリー] タブは次のようになります。

1 秒あたりのサンプル数は 1 未満です。これにより、詳細のドリルダウン、ホット メソッド、および概要タブが実質的に役に立たなくなります。最初の調査の結果、メソッド サンプリングがデフォルトの 10 ミリ秒に設定されていることが判明しました。この予期しない結果は、90 秒の約 98% が、さまざまなデータベース読み取りの実行中にソケット I/O の待機に費やされたためです。 、そのため、残りの約 2% の時間のメソッド サンプルしか取得していません。

データベース結果の待機に最も時間を費やしているトレースを特定するために、I/O バウンドのサンプルをメソッド時間に含めるにはどうすればよいですか? このプロセスには複数の場所でデータベース クエリが含まれており、これらのクエリは他の複数の場所から呼び出されるため、低速な呼び出しパスを推測するのは簡単ではありません。

com.sun.management.jmxremoteJVM 引数を使用して SSL 構成の JMX ポートを公開するリモート サーバーで Java プロセスを実行しています。このプロセスでは、自己署名証明書を含むキーストアが使用されます。

このリモート JMX ポートに接続するために、ローカル マシンで Java Mission Control (JMC) を実行しています。リモートキーストアから自己署名証明書をインポートしたトラストストアで JMC をセットアップしました。これはすべて素晴らしいことで、安全な SSL で期待どおりに接続できます。

最近、自己署名証明書の詳細を確認したところ、JMC を使用してリモート プロセスに接続できないと予想していたため、1 か月前に有効期限が切れていたことに驚きましたが、接続できました。期限切れの警告なしで問題ありません。

トラストストアなしで JMC を実行し、接続しようとすると証明書パス構築例外が発生するため、実際にこの証明書を使用していることを確認しました。SSL デバッグも調べたところ、証明書が使用されていることがわかります。

期限切れの証明書を使用してこの接続を確立できる理由を誰かに説明してもらえますか? このプロセスがブラウザで接続した RESTful サービスを公開した場合、接続できないと予想されるか、警告が表示されるだけでしょうか (または、JMC のように何も表示されません)。

御時間ありがとうございます。