On 5/26/2019 12:52 PM, Joe Doupnik wrote:
I do queries while indexing, have done so for a long time, without
difficulty nor memory usage spikes from dual use. The system has been
designed to support that.
Again, one may look at the numbers using "top" or similar. Try Solr
v8.0 and 8.1 to see the difference which I experience here. For
reference, the only memory adjustables set in my configuration is in the
Solr startup script solr.in.sh saying add "-Xss1024k" in the SOLR_OPTS
list and setting SOLR_HEAP="4024m".
There is one significant difference between 8.0 and 8.1 in the realm of
memory management -- we have switched from the CMS garbage collector to
the G1 collector. So the way that Java manages the heap has changed.
This was done because the CMS collector is slated for removal from Java.
https://issues.apache.org/jira/browse/SOLR-13394
Java is unlike other programs in one respect -- once it allocates heap
from the OS, it never gives it back. This behavior has given Java an
undeserved reputation as a memory hog ... but in fact Java's overall
memory usage can be very easily limited ... an option that many other
programs do NOT have.
In your configuration, you set the max heap to a little less than 4GB.
You have to expect that it *WILL* use that memory. By using the
SOLR_HEAP variable, you have instructed Solr's startup script to use the
same setting for the minimum heap as well as the maximum heap. This is
the design intent.
If you want to know how much heap is being used, you can't ask the
operating system, which means tools like top. You have to ask Java.
And you will have to look at a long-term graph, finding the low points.
An instananeous look at Java's heap usage could show you that the whole
heap is allocated ... but a significant part of that allocation could be
garbage, which becomes available once the garbage is collected.
Thanks,
Shawn
