On 08/01/18 15:16, Christopher Schultz wrote: <snip/>
>> Therefore, the first time that the GC runs, the process can take >> longer. Also, the heap is more likely to be fragmented and require >> a heap compaction. To avoid that, till now my strategy is to: - >> Start application with the minimum heap size that application >> requires - When the GC starts up, it runs frequently and >> efficiently because the heap is small > > I think this is a reasonable expectation for someone who doesn't > understand the Black Art of Garbage Collection, but I'm not sure it's > actually true. I'm not claiming that I know any better than you do, > but I suspect that the collector takes its parameters very seriously, > and when you introduce artificial constraints (such as a smaller > minimum heap size), the GC will attempt to respect those constraints. > The reality is that those constraints are completely unnecessary; you > have only imposed them because you think you know better than the GC > algorithm. Generally, the more memory available, the more efficient GC is. The general rule is you can optimise for any two of the following at the expense of the third: - low pause time - high throughout - low memory usage It has been a few years since I listened to the experts talk about it but a good rule of thumb used to be that you should size your heap 3-5 times bigger than the minimum heap used once the application memory usages reaches steady state (i.e. the minimum value of the sawtooth on the heap usage graph) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
