スレッドの競合:DXP 7.0の一般的なパフォーマンスの問題

この記事では、Liferay DXP 7.0内のスレッド競合に関連する一般的なパフォーマンスの問題について説明します。この問題に関する必要な情報とそのナビゲート方法については、以下をお読みください。

解決

スレッドの競合とは、同じオブジェクトのロックを待機している複数のスレッドがある場合です。 スレッドがロックを取得するのにかかる時間は、ロックを待機しているスレッドの数とともに増加するため、手に負えなくなる可能性があります。 これは、待機スレッドの1つにロックを与えるときにJVMがFIFOシステムを使用しないという事実によってさらに悪化しますいくつかの基準に基づいて1つを選択します。

症状は、スレッドの競合の重大度によって異なります。 影響を受けるスレッドが2、3個しかない場合、応答時間が遅くなるだけです。 何百も影響を受ける場合、Liferayプラットフォームもまったく応答しなくなる可能性があります。

ロギングの例を次に示します。

"http-/0.0.0.0:8280-248" daemon prio=10 tid=0x00007fbd0018b780 nid=0x484d waiting for monitor entry [0x00007fbbba490000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.log4j.Category.callAppenders(Category.java:205)
    - waiting to lock <0x000000066b869058> (a org.apache.log4j.spi.RootLogger)
    at org.apache.log4j.Category.forcedLog(Category.java:391)
    at org.apache.log4j.Category.log(Category.java:856)

この場合、 log4jRootLogger オブジェクトのロックを待機しており、ロックが取得されるまでその実行は中断されます(たとえば、状態がRUNNABLEではない)。 ID(0x0000 ...)検索すると、他の多くのスレッドも同じオブジェクトで待機していることが表示される場合があります。

log4jCategory.callAppenders() を呼び出そうとする数十または数百のスレッドがあり、同じオブジェクトのロックを待機している場合、それは間違いなくスレッド競合の問題です。

Spotifyの Online Thread Dump Analyzer は、この結果をきちんと要約しています。

spotify-performance-01.PNG

結論:

多数のスレッドがオブジェクトのロックを待機している場合、これはスレッドの競合の問題であり、この状態は複数のスレッドダンプの間中持続します。

これらの問題の考えられる解決策は次のとおりです。

  1. ボトルネックにそれほど依存しないように実行ロジックを変更する、または...
  2. いくつかの構成変更を行う、または...
  3. 受け取っている負荷を処理できるリソースをさらに追加します。
この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています