8

最近、YJP 11.0.9 を使用してアプリケーション (XMPP ベースのチャット サーバー) のストレス テストを開始しました。テスト中に、次の奇妙な動作に気付きました。

  1. サンプリングは、sun.misc.Unsafe.unpark(Object) が CPU の 60% を使用していることを示しています。
  2. 同じアプリのトレースでは、LockSupport.park(Object) が CPU の 52% を使用したことが示されています。

結果を確認するために複数のテストを行い、毎回同様の結果が得られました.

パーク解除に 60% の時間がかかる理由と、トレースが正反対の結果を示す理由を理解できません。

誰かがこれらの結果を理解するのを手伝ってくれますか? ここで何か不足していますか？

環境：

Java -バージョン
Java バージョン「1.6.0_31」
Java(TM) SE ランタイム環境 (ビルド 1.6.0_31-b04)
Java HotSpot(TM) 64 ビット サーバー VM (ビルド 20.6-b01、混合モード)
4

3 に答える 3

11

の高い CPU 時間は、過剰なコンテキスト スイッチングUnsafe.unparkの兆候です。コンテキストスイッチがどれほど高価であるかを理解するための記事は次のとおりです。

コンテキストの切り替えにはどのくらいの時間がかかりますか?

Linux で CS カウントを確認する最も簡単なオプションは runvmstat <seconds>です。

高い CS が確認されたら (例: コアあたり/秒あたり 10K の切り替え)、問題のあるスレッドを取得し (YJP のスレッドを CPU 時間で並べ替えることができます)、実行strace -p <pid> -cして切り替えの原因を見つけます。たとえば、スレッドがソケットから読み取っています。この場合、ソケット バッファを増やすと役立つ場合があります。

于 2015-04-02T13:47:13.343 に答える
3

読み取り/書き込み/パーク/ロックなどの特定の低レベルのブロックコマンドでは、実際に操作がブロックされているときにCPUを消費していると想定されるため、「CPU」時間は過大評価されます。unpark / parkが両方とも高いという事実は、問題があることを示唆していますが、2つのパーセンテージのうち低い方を推定値として使用する必要があると思います。

于 2012-10-19T11:58:31.493 に答える
0

I learned the hard way that you can also have high CPU usage % on LockSupport.parkNanos() if you call multiple times the method and your sleep argument is in the order of nanoseconds:

while(true){
  // code logic
  LockSupport.parkNanos(100);
}

Simply changing to microseconds helped me resolve my issue. I also tried it on my local machine and was able to reproduce the high CPU usage %, and saw it drastically improve after going for microseconds.

于 2021-09-10T18:07:38.803 に答える