Just to share some experience if someone hits the same problem. We had huge problems on Win7 64bit, JVM 64bit 1.7.0_07, (a few days old trunk version, 5.0, default codec) solr under tomcat thread queue limited to 20 . NRTCaching and MMAP have the same problems (no updates , just search). Unmap hack was on
Problem: After hitting it for 15 minutes with 10 search threads, gc() did not manage to catch-up and free enough memory and the server repeatably spiralled to OOM (giving more max heap did not help as well). Server is running on 8 cores, and 10 client threads are normally not an issue. Observations: - Tweaking jvm memory and gc() options did not help at all. - exactly the same configuration and tests on 3 linux flavours had absolutely no problems. - Win using FSDirectory works slower, but stable - When "OOM" spiralling happens, major culprits are, by occupied memory and Noo of instances: o.a.l.util.WeakIdentityMap$IdentityWeakReference java.util.concurrent.ConcurrentHashMap$HashEntry java.util.concurrent.ConcurrentHashMap$HashEntry[] - if pausing search requests for really long time (5 to 10 minutes!) these references get eventually released. ---------- I know java+MMAP on win platforms has problems (slowly releasing mapped regions), but I did not expect it is that bad, to the point of being useless. It is not an itch currently, all our production is on linux, but if someone has an idea how to work around it, we would be glad to try it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
