On 6/24/2021 8:55 AM, Webster Homer wrote:
SOLR_JAVA_MEM="-Xms32768m -Xmx32768m"
Change "32768m" to "31g". You'll actually have MORE heap available at 31GB than at 32GB. Screwy, I know. It's because at 32GB, Java has to use 64-bit pointers. Below that, it can use 32-bit.
On several posts on Solr GC configuration I noticed that -XX:+UseLargePages is set, but little to say why this would be useful. For it to work Large Memory Pages needs to be enabled as described here https://www.oracle.com/java/technologies/javase/largememory-pages.html
If the OS does not have Huge Pages set aside, that Java option does nothing at all. If the OS does have huge pages available, then Java will use them if you give it that option.
I'm not an expert in GC tuning so any advice would be appreciated.
The key to good GC performance -- make it unnecessary for Java to EVER do a full GC. No matter what collector you have chosen, if Java does a full GC, you're paused, potentially for a REALLY long time. With a heap as large as yours, you can be sure it WILL be slow. I was seeing pauses of 10-15 seconds, and that was with an 8GB heap.
Are there ANY humungous allocations still happening? If there are, then the only way Java can collect that garbage is a full GC. Maybe bump the region size up to its max, 32MB? How many documents do you have in your largest cores?
Thanks Shawn
