OK... The fix I thought would fix it didn't fix it (which was to use the commitWithin feature). What I can gather from `ps` is that the thread has pages locked in memory. Currently I'm using native locking for Solr. Would switching to simple help alleviate this problem?
Chris On Jun 4, 2011, at 2:48 PM, Chris Cowan wrote: > I found this thread that looks similar to what's happening on my system. I > think what happens is there are multiple commits happening at once from the > clients and it's causing the same issue. I'm going to use the commitWithin > argument to the updates to see if that fixes the problem. I will report back > with any findings. > > Chris > > On Jun 1, 2011, at 12:42 PM, Jonathan Rochkind wrote: > >> First guess (and it really is just a guess) would be Java garbage >> collection taking over. There are some JVM parameters you can use to >> tune the GC process, especially if the machine is multi-core, making >> sure GC happens in a seperate thread is helpful. >> >> But figuring out exactly what's going on requires confusing JVM >> debugging of which I am no expert at either. >> >> On 6/1/2011 3:04 PM, Chris Cowan wrote: >>> About once a day a Solr/Jetty process gets hung on my server consuming 100% >>> of one of the CPU's. Once this happens the server no longer responds to >>> requests. I've looked through the logs to try and see if anything stands >>> out but so far I've found nothing out of the ordinary. >>> >>> My current remedy is to log in and just kill the single processes that's >>> hung. Once that happens everything goes back to normal and I'm good for a >>> day or so. I'm currently the running following: >>> >>> solr-jetty-1.4.0+ds1-1ubuntu1 >>> >>> which is comprised of >>> >>> Solr 1.4.0 >>> Jetty 6.1.22 >>> on Unbuntu 10.10 >>> >>> I'm pretty new to managing a Jetty/Solr instance so at this point I'm just >>> looking for advice on how I should go about trouble shooting this problem. >>> >>> Chris >
