Hi all, we are facing a high memory usage in our Solr 3.6 master (not in the slaves) even during "idle" (non indexing) periods.
container: Tomcat 6.0.29 maxthreads: 1.5k (i think this setting is wrong, 300 would be enough) solr: solr 3.6.0 setup: multitenant environment with 120+ cores and near 5M docs spread over all indexes. uptime: 100+ days qps on this machine: 10 qps used heap: 8gb JVM params: -Djava.util.logging.config.file=/opt/opensearch/tomcat/conf/logging.properties -Dmaster=true -Dmaster.url="" -Xms5G -Xmx10G -XX:MaxPermSize=256m -XX:SurvivorRatio=5 -XX:NewRatio=2 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=22222 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/opensearch/tomcat/endorsed -Dcatalina.base=/opt/opensearch/tomcat -Dcatalina.home=/opt/opensearch/tomcat -Djava.io.tmpdir=/opt/opensearch/tomcat/temp I think we have a high memory usage due to the next report: char[] 3.1M instances 5.3Gb -----> this is what i'm talking about. LinkedHashMap$Entry 2M instances 121Mb String 1.48M 53Mb Checking for "cg roots" at all these instances, i found that almost all these references are contained in ISOLatin1AccentFilter.output -> TokenStreamImpl - Map$Entry -> Map -> CloseableThreadLocal -> TokenizerChain Do we had to add any CMS param to the JVM params? Or is this a memory leak due to the ThreadLocal's? I verified that those char[] didn't belong to FieldCache.default, so this high memory usage is not due the faceting and high cadinality values. PS: we reduced the number of threads and memory (and char[] instances) decreased significantly. -- Un saludo, Samuel García.
