Any one else see this, and anything to do about it? Happens when moving patients to a temporary list. Sometimes you can just click past it and everything is OK, other times not.
And on a maybe related note, what would be a good java memory setting for SOLR? We have just under 100 million documents in our index, and are currently at 2g for our java memory (see below):
SOLR_HEAP="${SOLR_HEAP:-2g}"
JAVA_MEM_OPTS=("-Xms$SOLR_HEAP" “-Xmx$SOLR_HEAP”)
I see some errors in the log related to timeouts waiting for SOLR, so wondering if changing this value would help.
Thanks,
Eric
I don’t think I’ve seen this error before.
We have 6g set for SOLR, with 200M documents. Solr memory-maps a lot of memory however, so if we look at the resident set size, it’s 15GB, and the virtual memory size is 3TB. These memory-mapped files are not a part of the Java Heap, but the Java process is still using lots of physical memory. So, increasing the Java heap is not necessarily doing you a favor in performance. It just depends. Cached query results will be in the Java heap, since they aren’t stored on disk, but the indexes are on disk, so when running a query if those portions of the index files needed to run the query are already in memory, the query will run faster.
Generally, garbage collection takes less than 1% of CPU time, unless Solr is struggling at near maximum memory. That can be checked on either by attaching jconsole to Solr, and looking at its memory graphs, or by looking at the gc log Solr output, under solr-8.*/server/logs/solr_gc.log. You can see how frequent and how long each GC cycle takes.