Make sure your Tomcat instances are started each with a max heap size that adds up to something a lot lower than the complete RAM of your system.
Frequent Garbage collection means that your applications request more RAM but your Java VM has no more resources, so it requires the Garbage Collector to free memory so that the requested new objects can be created. It's not indicating a memory leak unless you are running a custom EntityProcessor in DIH that runs into an infinite loop and creates huge amounts of schema fields. ;-) Also - if you are doing hot deploys on Tomcat, you will have to restart the Tomcat instance on a regular bases as hot deploys DO leak memory after a while. (You might be seeing class undeploy messages in catalina.out and later on OutOfMemory error messages.) If this is not of any help you will probably have to provide a bit more information on your Tomcat and SOLR configuration setup. Chantal On Thu, 2012-02-16 at 16:22 +0100, Matthias Käppler wrote: > Hey everyone, > > we're running into some operational problems with our SOLR production > setup here and were wondering if anyone else is affected or has even > solved these problems before. We're running a vanilla SOLR 3.4.0 in > several Tomcat 6 instances, so nothing out of the ordinary, but after > a day or so of operation we see increased response times from SOLR, up > to 3 times increases on average. During this time we see increased CPU > load due to heavy garbage collection in the JVM, which bogs down the > the whole system, so throughput decreases, naturally. When restarting > the slaves, everything goes back to normal, but that's more like a > brute force solution. > > The thing is, we don't know what's causing this and we don't have that > much experience with Java stacks since we're for most parts a Rails > company. Are Tomcat 6 or SOLR known to leak memory? Is anyone else > seeing this, or can you think of a reason for this? Most of our > queries to SOLR involve the DismaxHandler and the spatial search query > components. We don't use any custom request handlers so far. > > Thanks in advance, > -Matthias >
