問題の説明:
オンラインサービスが突然、ハングアップサービスログはすべてフルダボスレッドプールを発見したかどうかを確認するために呼び出すことはできません。
2019-11-22 14:35:26.271 WARN 26516 --- [New I/O server worker #1-2] c.a.d.c.t.support.AbortPolicyWithReport : [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.10.26:12350, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 6786 (completed: 6586), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.10.26:12350!, dubbo version: 2.6.2, current host: 192.168.10.26
死亡またはどこデッドロックが発生したのサイクルがある場合ではない多くのトラフィックが、スレッドが急増したが、憶測であってもよいです。
死のサイクルがある場合まず、CPUの使用率サーバーが正常範囲内で見つけたものを検出、基本的に除外しました。
まず、サービスのプロセスを見つける使用してjstack
、コマンドdump
スレッド分析を。
"DubboServerHandler-192.168.10.26:12350-thread-200" #240 daemon prio=5 os_prio=0 tid=0x00007ffa7c141800 nid=0x6c89 waiting on condition [0x00007ffa17c7c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0d24020> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:441)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:362)
at redis.clients.util.Pool.getResource(Pool.java:49)
at redis.clients.jedis.JedisPool.getResource(JedisPool.java:226)
at (RedisHelper.java:322)
at (RedisHelper.java:106)
at BlockResourceManager.java:54)
- locked <0x00000000e0ec22d0>
あなたは、最後のスレッドを見ることができるlocked <0x00000000e0ec22d0>
他の状態はスレッドがある一方で、それがロックして保持しています、waiting to lock <0x00000000e0ec22d0>
。
このスレッドが他のスレッドがブロックされているにつながっているようです。
だから、このスレッドの原因はクイックリリースは、それをロックすることはできません何ですか?
それからあるべき、上記の情報を見て続行JedisPool
の取得JedisClient
が、クライアントがプールの終わりには利用できなかった、それがブロックされています。
最後の理由は、排出されるクライアントリソースが得られ、プールに戻らないクライアントを使用する方法です。