I jstack through the analysis of our solr thread found that the total number of threads 1169 of which 1037 threads are the wait state, the 1037 threads, there are two types of threads is very large, 486 threads with same trace trace searcherExecutor-5694-thread -1, searcherExecutor-5694-thread-1 - priority: 5 - threadId: 0x00007f0f0401f000 - nativeId: 0x406a - state: WAITING stackTrace: java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park (Native Method) - parking to wait for <0x00007f1787000578> (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 java.util.concurrent.LinkedBlockingQueue.take (LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask (ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:617) at java.lang.Thread.run (Thread.java:745) Locked ownable synchronizers: - None
546 threads with same stack trace commitScheduler-5592-thread-1 commitScheduler-5592-thread-1 - priority: 5 - threadId: 0x00007f1174e56000 - nativeId: 0x2120 - state: WAITING stackTrace: java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park (Native Method) - parking to wait for <0x00007f174d2011b0> (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 java.util.concurrent.ScheduledThreadPoolExecutor $ DelayedWorkQueue.take (ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor $ DelayedWorkQueue.take (ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask (ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:617) at java.lang.Thread.run (Thread.java:745) Locked ownable synchronizers: - None ---------------------------------- My question is, what is the relationship between the number of threads in the commitScheduler thread pool and what? The number of searcherExecutor thread pool and the above have a relationship, why so much, thank you!
