# 500 Internal Server Error that I \*think\* is related to SOLR garbage collection

**URL:** https://discourse.project-emerse.org/t/500-internal-server-error-that-i-think-is-related-to-solr-garbage-collection/65
**Category:** Uncategorized
**Created:** [February 18, 2021, 9:04pm UTC](https://discourse.project-emerse.org/t/500-internal-server-error-that-i-think-is-related-to-solr-garbage-collection/65 "2021-02-18T21:04:08Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![EricMeeks](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@EricMeeks](https://discourse.project-emerse.org/u/EricMeeks)
#### Post date: [February 18, 2021, 9:04pm UTC](https://discourse.project-emerse.org/t/500-internal-server-error-that-i-think-is-related-to-solr-garbage-collection/65/1 "2021-02-18T21:04:08Z")

</div>

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

---

<div class="post-metadata">

### Author: ![mcclaink](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.project-emerse.org/mcclaink/32/8_2.png) [@mcclaink](https://discourse.project-emerse.org/u/mcclaink)
#### Post date: [February 18, 2021, 9:57pm UTC](https://discourse.project-emerse.org/t/500-internal-server-error-that-i-think-is-related-to-solr-garbage-collection/65/2 "2021-02-18T21:57:00Z")

</div>

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.
