I know theres no hard answer, and I know the Xms and Xmx should be the same, but it was a set it and forget it sort of thing from years ago. I will definitely be changing it but figured I may as well figure out as much as possible from this user group resource. as far as the raw GC data goes: https://pastebin.com/vBtpYR1W
(i dont know if people still use pastebin) i can get more if needed. the systems dont do ANY indexing at all, they are search only slaves. they share resources only with a DB install, and one node will never do both live search and live DB. If theres any more info youd like I would be happy to provide, this is interesting. On Thu, Dec 5, 2019 at 2:41 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 12/5/2019 11:58 AM, David Hastings wrote: > > as of now we do an xms of 8gb and xmx of 60gb, generally through the > > dashboard the JVM hangs around 16gb. I know Xms and Xmx are supposed to > be > > the same so thats the change #1 on my end, I am just concerned of > dropping > > it from 60 as thus far over the last few years I have had no problems nor > > performance issues. I know its said a lot of times to make it lower and > > let the OS use the ram for caching the file system/index files, so my > first > > experiment was going to be around 20gb, was wondering if this seems > sound, > > or should i go even lower? > > The Xms and Xmx settings should be the same so Java doesn't need to take > special action to increase the pool size when more than the minimum is > required. Java tends to always increase to the maximum as it runs, so > there's usually little benefit to specifying a lower minimum than the > maximum. With a 60GB max heap, Java is likely to grab a little more > than 60GB from the OS, regardless of how much heap is actually in use. > > If you can provide GC logs from Solr that cover a signficant timeframe, > especially heavy indexing, we can analyze those and make an estimate > about the values you should have for Xms and Xmx. It will only be a > guess ... something might happen later that requires more heap. > > We can't make recommendations without hard data. The information you > provided isn't enough to guess how much heap you'll need. Depending on > how such a system is used, a few GB might be enough, or you might need a > lot more. > > > https://lucidworks.com/post/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/ > > Thanks, > Shawn >
