<div dir="ltr">Hi Thomas, thank you for the feedback. Please see inline. <br><div class="gmail_extra"><br><div class="gmail_quote">On 31 October 2017 at 16:22, Thomas Schatzl <span dir="ltr"><<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ruslan,<br>
<span class="gmail-m_1709387421755279917gmail-"><br>
On Mon, 2017-10-30 at 19:06 +0100, Ruslan Synytsky wrote:<br>
> Hi guys, I'm interested in improvements in this direction as well.<br>
> Let me share the statistical experience from Jelastic customers who<br>
> run Java stacks in containers for a long time.<br>
><br>
> We set the minimum Xmx to 32m by default as we believe majority wants<br>
> to start from the minimum, specifically in the "micro" world<br>
> (services, containers). G1 GC provides good enough elasticity of<br>
> memory allocation. You can grow up quickly, and important to scale<br>
> down later when the load goes away.<br>
><br>
> By default, Xmx is 80% of available RAM with container limits. It<br>
> works great for the majority of our users. We track OOM Kill events<br>
> and send alerts to the users. So the numbers are based on the real<br>
> end users applications.<br>
><br>
> We keep 80% from max by default always, even if users allocate a<br>
> bigger amount of RAM, for two reasons: 1 - it's easier to remember<br>
> the defaults and 2 - unused resources are not reserved with<br>
> containers, so if Java does not use it - no problem, they are free,<br>
> and at the same time additional memory available for native non-heap<br>
> data or for other processes, just like an insurance.<br>
<br>
</span>Thanks for your insights into real-world usage. So maybe the suggested<br>
50% as default for small heaps is indeed a bit too conservative.<br></blockquote><div>Understanding of the situations when people rely on the default heuristic will be really helpful to make a final decision... From my personal experience, if you do not specify Xmx you always get troubles at the end. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_1709387421755279917gmail-"><br>
> Big memory and big data solutions - everything like this requires a<br>
> fine-tuning, the customers who run such stacks definitely do not rely<br>
> on the default heuristic. You can always find instructions and<br>
> recommended RAM usage configs for these stacks. Some solutions even<br>
> use direct memory access, a small heap size is preferable for them.<br>
> In general, it means you have to do a customization if you want to<br>
> get a stable solution. <br>
><br>
> To make it simple, we came up with a supervisor script that<br>
> applies custom memory configs. As result, customers can define the<br>
> needed parameters with env variables in a container if they do not<br>
> want to rely on the heuristic. <br>
><br>
> Btw, is there any guaranteed way to pass Xmx and Xms to java process<br>
> w/o any external scripts? I mean, it will be cool if java can check<br>
> env variable like XMX and if it exists apply. <br>
><br>
<br>
</span>There is JAVA_TOOL_OPTIONS, which are always prepended to the java VM<br>
command line. See the description [0] for more information.<br></blockquote><div>Indeed this option is close to what I was looking for! But seems JAVA_TOOL_OPTIONS does not work for Xmx. Just a quick test with Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)</div><div class="gmail_quote"><br></div><b>Default</b><br>$ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize<br> size_t MaxHeapSize = 643825664 {product} {command line}<br><b><br>Define Xmx = 2GB via JAVA_TOOL_OPTIONS </b></div><div class="gmail_quote">$ export JAVA_TOOL_OPTIONS="-Xmx2g" <br>$ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize<br>Picked up JAVA_TOOL_OPTIONS: -Xmx2g<br> size_t MaxHeapSize = 643825664 {product} {command line}<br><br>It says that Xmx has been picked up, but in reality it has not been applied. <br><br><b>Define Xmx = 3GB via _JAVA_OPTIONS </b><br>$ export _JAVA_OPTIONS="-Xmx3g" <br>$ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize<br>Picked up JAVA_TOOL_OPTIONS: -Xmx2g<br>Picked up _JAVA_OPTIONS: -Xmx3g<br> size_t MaxHeapSize = 3221225472 {product} {command line}<br><br><div>Now it works as expected. However, another issue is that _JAVA_OPTIONS is undocumented and hotspot-specific?...</div><div><br></div><div>Also important to mention that _JAVA_OPTIONS trumps command-line arguments, and command-line arguments trump JAVA_TOOL_OPTIONS. That gives a quite good flexibility. Because sometimes you may want to override command line args and sometimes you need just to provide better deafults, but if users specify command line args use them. In other words, I believe, if we can a) improve JAVA_TOOL_OPTIONS (or introduce a new name like JAVA_OPTIONS_DEFAULT) for enabling people to specify Xmx via this env var and b) make _JAVA_OPTIONS as a standard/documented option, then this will solve the existig dificulties and provide enough flexibility. </div><div> <br></div><div>Thanks </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think this is what you were looking for.<br>
<br>
Thanks,<br>
Thomas<br>
<br>
[0] <a href="https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/envvars002.html" rel="noreferrer" target="_blank">https://docs.oracle.com/javase<wbr>/8/docs/technotes/guides/<wbr>troubleshoot<br>
/envvars002.html</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_1709387421755279917gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="font-family:"Times New Roman""><span style="font-family:Calibri,sans-serif;font-size:15px">Ruslan</span><br style="font-family:Calibri,sans-serif;font-size:15px"><span style="font-family:Calibri,sans-serif;font-size:15px">CEO @ </span><span style="font-family:Calibri,sans-serif;font-size:15px"><a href="https://jelastic.com/" target="_blank">Jelastic</a></span><br style="font-family:Calibri,sans-serif;font-size:15px"></div><div style="font-family:"Times New Roman""><br></div><div style="font-family:"Times New Roman""><br></div><div style="font-family:"Times New Roman""><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>