0

いくつかの結果をキャッシュし、あまりにも多くのws呼び出しを回避するために、ehcacheを使用するWebサービスクライアントがあります。

どうやら、このwsクライアントが呼び出されたサーバー(Weblogic OSB上)はハングし、ログに何も書き込まないようです...ただフリーズしてください!少しのトラフィックがあるとすぐに。

完全なスレッドダンプはここにあります:

http://pastebin.com/rdVyxjNc

以下は、 <0x8a03c9c0>を待つために駐車する私にはあまり明確ではないものです

しかし、スレッドダンプで0x8a03c9c0への参照を見つけることができません。

このサーバーをフリーズさせる可能性のあるスレッドダンプに何かがありますか?

ありがとう

searchByTemplate.data" prio=3 tid=0x0115b400 nid=0x5e waiting on condition [0x5ef7f000..0x5ef7fbf0]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x8a03c9c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963)
        at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
        ...
4

1 に答える 1

2

強調表示したスレッドは、実際にはリクエストを処理するために「利用可能」であるため、問題はありません。Weblogic Oracle Service Busは、XML操作をXQueryに依存しています。XQueryは、ビッグデータペイロードに対して使用される場合、CPUとメモリの両方を集中的に使用することが知られています。

スレッドダンプを分析しました。スレッドダンプは、複数のスレッドがXMLの解析や、ArrayListなどの一部のデータ構造にメモリを割り当てようとするなどのタスクを実行している高いCPUパターンを明確に示しています。

「ハング」問題の原因として考えられる2つのシナリオを疑っています。

過剰なガベージコレクションとOldGenスペースの枯渇

HotSpot JVM 1.6以降には、下部にJavaヒープ使用率が含まれています。OldGenスペースが92%であることがわかります。これにより、スレッドダンプから見えるスレッドパターンが強化されます。

  1. PSYoungGen合計466944K、使用済み233472K [0xd1000000、0xfbc00000、0xfbc00000)
  2. edenスペース233472K、100%使用[0xd1000000,0xdf400000,0xdf400000)
  3. スペース233472Kから、0%使用[0xed800000,0xed800000,0xfbc00000)
  4. スペース233472Kに、0%使用[0xdf400000,0xdf400000,0xed800000)
  5. ParOldGen 合計1400832K、使用済み1297110K [0x7b800000、0xd1000000、0xd1000000)
  6. オブジェクトスペース1400832K、92%使用[0x7b800000,0xcaab5ac8,0xd1000000)
  7. PSPermGen合計262144K、使用済み167570K [0x6b800000、0x7b800000、0x7b800000)
  8. オブジェクトスペース262144K、63%使用[0x6b800000,0x75ba4ab0,0x7b800000)

CPUやJavaヒープメモリを消費する犯人スレッド

このシナリオでは、1つまたはいくつかのスレッドがXQueryを返さないなどのノンストップ処理に関与し、CPUサージとJVM競合を引き起こしている可能性があります。

今、私の推奨事項を以下に示します。

  • verbose:gcを有効にします。これにより、ガベージコレクションの頻度に沿ってJavaヒープのヘルスとフットプリントの評価を実行できます。
  • 次に問題が発生したときに、スレッドごとのCPU%分析を実行します。これにより、CPUやJavaヒープメモリを消費する特定のServiceBusリクエストを処理しているかどうかを判断できます。

次の分析フェーズで役立つように、私のブログの以下の記事を見つけてください。

冗長GC分析

JVMVerboseGCチュートリアル

Javaの高CPUトラブルシューティング

JavaHighCPUのトラブルシューティング

よろしく、PH

于 2012-12-15T02:02:35.070 に答える