Thanks Eric and Shawn, Your explanations help understand where SOLR may be spending its time. Sounds like compression can be a CPU and heap hog. (I'll try to confirm this with the heapdumps)
Initially we tried to keep the JVM heap sizes the same on both Solr 3.5 and 4.2.1, which was around 3GB ,which 3.5 handled well even with a 200QPS load. Moving to 4.2.1 with the same heap size instantly killed the Server. Changing the JVM to 6GB (double) did not help either. We were seeing higher CPU and higher heap usage. We later changed cache settings so as to reduce their sizes, increased the JVM to 8GB and we see an improvement. But over time, we do see that the Heap utilization slowly climbs as the 200QPS test is allowed to run, and sometimes leads to max heap being exceeded from the JConsole. So we see the jagged edge waveform which keeps climbing (GC cycles don't completely collect memory over time). Our test has a short capture from real traffic and we are replaying that via solrmeter. Thanks. Regards, -- Sandeep -- View this message in context: http://lucene.472066.n3.nabble.com/Solr-4-2-1-higher-memory-footprint-vs-Solr-3-5-tp4067879p4068150.html Sent from the Solr - User mailing list archive at Nabble.com.
