We currently have a 30G index with 73M of .tii files running on a 
machine with 4 Intel 2.27GHz Xeons with 15G of memory.

About once a second a process indexes ~10-20 smallish documents using 
the XML Update Handler. A commit happens after every update. However we 
see this behaviour even if the indexer isn't running.

The system is running under Tomcat6 with Solr 1.4.1 955763M - mark - 
2010-06-17 18:06:42 and Lucene 2.9.3 951790 - 2010-06-06 01:30:55

Out GC settings (the least worst we've found so far) currently look like 

-XX:+UseConcMarkSweepGC 
-XX:+CMSIncrementalMode 
-XX:+UseParNewGC
-XX:NewSize=5G 
-XX:SurvivorRatio=3 
-Xmx10G -Xss10M 
-XX:CMSInitiatingOccupancyFraction=40 
-XX:+UseCMSInitiatingOccupancyOnly

Everything is fine until we start to try and search at which point 
performance goes to hell with multi second response times and frequent 
full GC runs (approx every 15 seconds) looking like

2372.886: [Full GC 2372.886: [CMS2378.577: [CMS-concurrent-mark: 
5.912/5.913 secs] [Times: user=6.10 sys=0.01, real=5.91 secs] 
 (concurrent mode failure): 5242879K->5242879K(5242880K), 18.2557740 
secs] 9437183K->9409440K(9437184K), [CMS Perm : 30246K->30242K(50552K)] 
icms_dc=100 , 18.2558680 secs] [Times: user=18.20 sys=0.05, real=18.26 
secs] 

Looking at top jsvc is using 100% of CPU.

I'm baffled - I've had way bigger indexes than this before with no 
performance problems. At first it was the frequent updates but the fact 
that it happens even when the indexer isn't running seems to put paid to 
that.

One salient point - because of the frequent updates we don't have a 
queryResultCache configured.

Any ideas? Hints? Tips?

Simon



 

Reply via email to