397 liens privés
A few weeks ago I faced an interesting problem trying to analyze a memory consumption in my Java application (Spring Boot + Infinispan) running under Docker. The Xmx parameter was set to 256m, but the Docker monitoring tool displayed almost two times more used memory. Below we will try to understand the reasons of such a strange behavior and find out how much memory the app consumed in fact.
Je ne connaissais pas le Native Memory Tracker du jdk8
Petite formule saltstack pour faire utiliser les 3/4 de la RAM à la JVM:
"""
Xmx: {{ (((grains.mem_total|int) 3) / 4)|round|int }}M
Xms: {{ (((grains.mem_total|int) 3) / 4)|round|int }}M
"""
J'ai positionné cela dans les pillars.
C'est inspiré de https://mywushublog.com/2013/09/postgresql-salt-state/ (https://jeekajoo.eu/links/?crzrTg)
Cela évite d'avoir à se palucher un tuning manuel pour des machines dont les capacités mémoire sont différentes. Exemple sur ec2:
- m3.2xlarge = 30 G
- c3.2xlarge = 15 G
- c3.xlarge = 7.5 G
- m3.medium = 3.75 G
- ....
coude
en fait y'a plus simple.
comme mettre un Xmx ridiculement petit genre moins de 10M et tenter de charger un war qui demande plus.
Dans le billet, l'auteur a mis le code d'une servlet qui provoque justement un 'java.lang.OutOfMemoryError: Java heap space'
Ceci afin de tester que le heap dump peut bien se créer à l'endroit qu'on a prévu.
rajouter les options suivantes au lancement de java pour voir ce que fait le gc:
-Xloggc:/var/log/gc.log -XX:+PrintGCDetails Memory