<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Hi guys, some new findings related to this topic. Previously we got a great question from Stefan Johansson: </div><div><br></div>>> Another question, when <br>>> running in the cloud, what load is the user expecting us to compare <br>>> against, the overall system or the local container. I'm actually not <br>>> entirely sure what the getloadavg() call return in case of running in a <br>>> container.<br><br>> Good question! It depends on the used container technology. In short, if it’s a system</div><div class="gmail_quote">> container then it shows the load of the container, if it’s an application container then the </div><div class="gmail_quote">> load of the host machine. There is an article on a related topic </div><div class="gmail_quote">> <a href="https://jelastic.com/blog/java-and-memory-limits-in-containers-lxc-docker-and-openvz/">https://jelastic.com/blog/java-and-memory-limits-in-containers-lxc-docker-and-openvz/</a> <div><br></div><div>I found more details / info that will be useful for end users, there is a quick summary:  </div><div><ul><li>VMs - the problem does not exist as JVM gets loadavg of the parent virtual machine it’s running in.</li><li>Containers </li><ul><li>LXC - the problem does not exist, because <a href="https://github.com/lxc/lxcfs">LXCFS</a> is making Linux containers feel more like a virtual machine.</li><li>OpenVZ - the problem does not exist as every container has a virtualized view of /proc pseudo-filesystem  </li><li>Docker and runC - by default loadavg will be provided from the host machine, which is a kind of problem for determining the real load inside a container. However, the recent improvements in runC engine are solving this issue: <a href="https://github.com/opencontainers/runc/pull/1882">libcontainer: add /proc/loadavg to the white list of bind mount</a>. Also there is a useful related article - <a href="https://medium.com/@Alibaba_Cloud/kubernetes-demystified-using-lxcfs-to-improve-container-resource-visibility-86f48ce20c6">LXCFS for Docker and K8S</a>. So, we can assume that this solution will be available by default in the near future.</li></ul></ul></div><div>Also, some kind of a quick summary / "a state of JVM elasticity": </div><div><ul><li>G1 - the new options will be introduced soon: <i>G1PeriodicGCInterval, </i><i>G1PeriodicGCSystemLoadThreshold, G1PeriodicGCInvokesConcurrent, </i>the work is in progress.</li><li>Shenandoah - the leading GC in terms of elasticity at the moment (my personal opinion). Available options: <i>ShenandoahUncommitDelay, ShenandoahGuaranteedGCInterval.</i></li><li>OpenJ9 - introduced special options: <i>IdleTuningGcOnIdle, IdleTuningCompactOnIdle, IdleTuningMinIdleWaitTime. </i>However, the uncommitment is not fully transparent for end users, as a result it's harder to track the real usage. The only way to measure the effect is to monitor resident memory size <i>RES</i> using <i>top</i>. Also it implements different approach for checking idle sate - based on <i>samplerThreadStateLogic.</i> For more details please <a href="https://github.com/eclipse/openj9/issues/2312#issuecomment-431453020">check to this conversation</a>. </li><li>ZGC - the work is in the progress, there <a href="http://cr.openjdk.java.net/~pliden/zgc/zrelease_unused_heap/webrev.0">is a quick patch</a> to support releasing of memory back to the OS in <span class="gmail-il">ZGC. </span>If you want to try it out, the patch should apply to the latest jdk/jdk tree. Use the new option <i>-XX:+ZReleaseUnusedHeap</i>. A more refined version of the patch will most likely be upstreamed at some point in the future.</li><li>Azul C4 - seems like it's scalable vertically too. I sent clarification request to Deputy CTO, but have not received any feedback so far, so it's unknown how exactly it works. If anyone can share his/her personal experience than will be useful.</li></ul></div><div>Thanks everybody involved for moving this topic forward. </div><div>Regards </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><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/" style="color:rgb(17,85,204)" target="_blank">Jelastic</a></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>