Performances et lagUn statut « Killed » sans rapport de plantage, sans trace et sans le moindre avertissement est l'une des choses les plus déroutantes que puisse voir le propriétaire d'un serveur — parce que contrairement à presque tout autre échec, celui-ci n'est pas la faute du logiciel du jeu, et le logiciel du jeu n'a jamais l'occasion de dire quoi que ce soit à ce sujet.
Pourquoi l'arrêt est instantané et silencieux
La limite de mémoire d'un conteneur est appliquée par le noyau du système d'exploitation, pas par Java. Quand l'usage total de mémoire — le tas de Java, plus tout ce que Java alloue hors du tas, plus tout autre processus du conteneur — franchit cette limite, le noyau ne demande pas poliment. Il envoie un signal qui termine le processus immédiatement, sans que Java n'ait la chance de journaliser une exception, d'écrire un rapport de plantage, ou même de vider sa propre sortie. Un instant le serveur tourne ; l'instant suivant, le processus n'existe plus.
C'est aussi pourquoi le swap est désactivé par conception plutôt que par oubli : le swap laisserait un serveur dépassant sa limite de mémoire ramper au lieu d'être tué, échangeant un échec rapide et net contre un échec lent et dégradé souvent pire pour tous les joueurs connectés à ce moment-là — et cela au prix de la performance d'E/S NVMe sur laquelle est bâti le reste de la plateforme.
Ce qui utilise vraiment de la mémoire, au-delà de -Xmx
| Consommateur | Compte contre la limite du conteneur ? |
|---|---|
Le tas Java, jusqu'à -Xmx | Oui — c'est ce que contrôle ce flag |
| Piles des fils (une par fil d'extension, par gestionnaire de connexion) | Oui, et non inclus dans -Xmx |
| Tampons directs/hors-tas (très utilisés par Netty pour le réseau) | Oui, et non inclus dans -Xmx |
| Fichiers de région mappés en mémoire | Oui, bien que le noyau puisse les récupérer plus facilement sous pression |
| Tout autre processus du conteneur | Oui — une extension de carte web, un proxy embarqué, tout autre chose tournant à côté |
-Xmx réglé trop près de la limite du conteneurRégler -Xmx sur toute l'allocation de mémoire n'utilise pas les 4 Go en sécurité — cela garantit un arrêt par OOM dès que les piles de fils et les tampons réseau ont besoin de leur part, ce qui arrive sous charge ordinaire, pas sous charge inhabituelle. Laisser 10 à 20 % de la mémoire du forfait non assignés à -Xmx est ce qui utilise réellement le forfait en sécurité.
Diagnostiquer de quel type d'OOM il s'agit
- Vérifiez si cela arrive à un moment prévisible ou s'aggrave au fil de la session
Une fuite grimpe régulièrement tout au long de la session et finit par tuer quel que soit le coussin. Un problème de coussin tue à peu près au même niveau de mémoire à chaque fois, souvent lié au pic de joueurs.
- Regardez le graphique de mémoire sur une session complète, pas juste au plantage
Une montée constante qui ne redescend jamais entre les périodes calmes est la signature d'une fuite — généralement une extension gardant des références à des entités, joueurs ou chunks qu'elle devrait relâcher.
- Si c'est un problème de coussin, baissez
-Xmxavant de monter de forfaitUn plantage dû à un
-Xmxréglé trop haut est un problème de configuration qu'une montée de forfait a la chance de masquer plutôt que de corriger — à écarter avant de dépenser pour davantage de mémoire que la même mauvaise configuration finirait aussi par remplir.
Le serveur tient une session complète et chargée — le point où il mourait auparavant — avec la mémoire se stabilisant dans le motif en dents de scie normal du ramasse-miettes plutôt que de grimper jusqu'au plafond.