6

現在、次の方法でJMXを使用して合計スレッドCPU時間を取得しています。

private long calculateTotalThreadCpuTime(ThreadMXBean thread) {

    long totalTime = 0l;

    for (ThreadInfo threadInfo : thread.dumpAllThreads(false, false))
        totalTime += thread.getThreadCpuTime(threadInfo.getThreadId());

    return totalTime;
}

ThreadMXBeanは実際にはリモートプロキシであるため、この実際のメソッド呼び出しのパフォーマンスは秒単位で非常に高くなります。

これを行うより速い方法はありますか？

更新：これをパフォーマンスの監視に使用しています。測定値は「実時間」とJProfilerの両方であり、この方法で費やした時間の約85％を示しています。他にもいくつかのMXBean呼び出し（ランタイム、メモリ、GC）がありますが、はるかに安価です。ほとんどの場合、へのすべての呼び出しthread.getThreadCpuTimeがリモート呼び出しであるためです。

アップデート2：パフォーマンスの問題を示すJProfilerのスクリーンショット。

代替テキスト

4

5 に答える 5

3

非標準のAPIを使用する場合は、David RobertNadeauのブログの「Sun内部クラスを使用してJVMCPU時間を取得する」で説明されているように、にキャストOperatingSystemMXBeanしcom.sun.management.OperatingSystemMXBeanて呼び出すことができます。getProcessCpuTime()

于 2009-06-09T22:56:59.640 に答える
2

問題となるのは、通話のリモート性である必要があります。

私は最近、スレッドにCPU時間の使用を要求することに急上昇しましたが、それは信じられないほど高速でした。Webアプリケーション要求のコンテキストでは、それはほとんど測定不可能でした。ハードループに入った場合はコストがかかりますが、通常は操作の開始時と終了時に必要になります。

于 2009-09-19T07:53:46.180 に答える
1

最適化：

  • スレッドプール内でgetThreadCPUTimeを呼び出します。これは、ネットワークにバインドされているように見えるためです。
  • スレッドがにあることがわかった場合は常に、Thread.STATE.TERMINATEDその名前をマップに保持し、次回のクエリをスキップします。
于 2009-06-10T09:07:53.397 に答える
1

パフォーマンスの低下の原因は、thread.getThreadCpuTime()willの各呼び出し（リモートプロキシの場合）がRMI / Remote JMX呼び出しを引き起こす可能性が高いことです。これは、特にメッセージが実際にTCP経由で送信される場合はもちろん高価です（場合によってはlocalhostの外部）。 （JMX 1.4仕様、7.3章を参照）

JMXは一度に複数の属性の取得thread.getThreadCpuTime(long)を定義しますが、これはJMX属性ではなく、リモートメソッド呼び出しであるため、ここでは役に立ちません（さらに、メソッドが呼び出されるThreadInfoオブジェクトは呼び出しごとに異なります）

残念ながら、JMX 1.4仕様では、 「複数のオブジェクトの複数のメソッドを呼び出して、それらの戻り値を返す」などの定義はありません。したがって、これらの呼び出しの同時呼び出し（時間の節約にはなりますが、労力の削減にはなりません）の他に、ここでは（互換性のある）最適化については認識していません。

于 2013-03-26T18:48:25.507 に答える
0

この情報の使用をどのように計画しているのか、詳しく教えてください。JVMTIベースのエージェントを使用してスレッドのCPU時間を取得できます。これは、JMXよりもわずかに優れたパフォーマンスを発揮するはずです。「恐ろしい」パフォーマンスの結論につながるJMXアプローチのオーバーヘッドをどのように測定しましたか？

于 2009-06-09T20:05:14.963 に答える