Mémoire : combien allouer et pourquoi pas toute

Le graphique de mémoire dans le panneau effraie les nouveaux venus : il est presque toujours élevé. C’est un comportement normal de Java.

Comment le lire

Java alloue la mémoire à l’avance et ne la libère que lors du garbage collection. La dent de scie sur le graphique — une utilisation qui monte puis chute brutalement après la collecte — est le signe d’un serveur sain.

Un problème se présente autrement : la courbe reste collée au plafond et ne redescend pas après les creux. Cela signifie que la mémoire n’est pas libérée — soit la mémoire est réellement trop faible, soit il y a une fuite.

Signes de manque

• OutOfMemoryError dans le journal — analyse.
• Des gels de plusieurs secondes qui s’aggravent avec le temps de fonctionnement.
• Le serveur tourne bien après un redémarrage et se dégrade en soirée.

Fuite

Si la consommation augmente linéairement et ne baisse pas, cherchez le coupable :

spark heapsummary

Il s’agit généralement d’un plugin qui accumule des données, ou d’un mod avec des chunk loaders — Spark.

Une mesure temporaire consiste à redémarrer automatiquement une fois par jour. La solution définitive est de trouver et de mettre à jour le coupable.

Ne pas tout allouer

Outre le heap, le processus a besoin de mémoire pour les métadonnées, les threads et les tampons, et le conteneur a besoin de mémoire pour le système. Le panneau Millida en tient compte lui-même en définissant les limites de heap selon le plan — vous n’avez pas à y toucher manuellement.

Quand changer de plan

Lorsque la consommation de pointe atteint systématiquement la limite en fonctionnement normal et que le profil ne montre pas de fuite — Changer de plan.