この記事では、Liferay DXP 7.0のスレッド競合に関連する一般的なパフォーマンスの問題について説明します。 この問題についての必要な情報と、それをナビゲートする方法については、以下をお読みください。
決議
スレッドの競合とは、同じオブジェクトをロックするために複数のスレッドが待機している場合です。 これは、ロックを待っているスレッドの数に応じて、ロックを取得するまでの時間が長くなるため、手に負えなくなることがあります。 これは、待機中のスレッド-のいずれかにロックを付与する際に、JVMがFIFOシステムを利用しないという事実によってさらに悪化しています。
症状は、スレッドの競合の重症度によって異なります。 影響を受けるスレッドが数本しかない場合は、レスポンスが遅くなるだけかもしれません。 数百人が影響を受けた場合、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)
この場合、 log4j は、 RootLogger オブジェクトのロックを待っており、ロックが取得されるまでその実行は中断されています(例えば、状態はRUNNABLEではありません)。 ID (0x0000...)を検索すると、他の多くのスレッドも同じオブジェクトを待っていると表示されるかもしれません。
もし、 log4j'の Category.callAppenders() を呼び出そうとしているスレッドが十数個以上、あるいは数百個以上ある場合、同じオブジェクトをロックするのを待っているのは間違いなくスレッドの競合の問題です。
Spotifyの Online Thread Dump Analyzer は、この結果をきれいにまとめています。
結論。
多くのスレッドがオブジェクトをロックするために待機している場合、この状態が複数のスレッドダンプを通して持続するのはスレッドの競合の問題です。
これらの問題の解決策として考えられるのは
- ボトルネックにあまり頼らないように実行ロジックを変更したり
- 設定を変更したり...
- それが受けている負荷を処理できるリソースを追加します。