On 4/27/2014 12:29 AM, Toke Eskildsen wrote: > Shawn Heisey [s...@elyograg.org] wrote: >> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201404.mbox/%3c53567525.30...@elyograg.org%3E > >> Quick summary: Nineteen defined cores, four of them active, very low >> total query rate on the server of about 8 per second. 150 threads are >> created by this. Tomcat and Jetty default to allowing 200 threads. >> Solr will not scale with container defaults, which is why the example >> sets maxThreads to 10000. > > Are you talking about performance or deadlocks?
Deadlocks. It's not a performance thing -- with only 200 threads allowed, Jetty will refuse to start the additional threads that a large Solr install wants to start. The amount of work that those threads need to do is probably not huge unless query volume is high. If they can't even start, Solr will pause, deadlock, or simply not work right, depending on exactly what it is and how long it takes before the new thread is allowed to run. A large number of the threads that get created do not have good names, just "Thread-NNNNNN" ... others have names that don't mean anything to me, like qtpNNNNNNNNN-NNNNNN. http://paste.fedoraproject.org/97268/39860919/ At this point I can't tell whether it's Jetty, Lucene, or Solr that creates the threads that have useless names. If it's Lucene/Solr, then we need to work on that. If it's Jetty, we can file a bug and look into creating a patch. It may be both. The Solr example from branch_4x shows 24 threads in jconsole, so I would guess that most of the threads I am seeing are being created by Solr, not Jetty. A handful of the threads on my setup are those required for remote JMX. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
