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