ACLClouds
ACLClouds

Le processus s’arrête avec le code 137

Confirmer un arrêt OOM, réduire la mémoire consommée et éviter une boucle de redémarrage. Il peut aussi suivre un arrêt forcé depuis le panel.

Le code 137 correspond généralement à un SIGKILL, souvent envoyé lorsque le conteneur dépasse sa limite mémoire. Il peut aussi suivre un arrêt forcé depuis le panel.

Procédure étape par étape

  1. Vérifier le contexte

    Cherchez un pic mémoire, Killed ou un redémarrage juste après une tâche lourde.

  2. Limiter les charges

    Réduisez cache, concurrence, taille des lots ou nombre de workers. Évitez de charger de gros fichiers entièrement en RAM.

  3. Chercher une fuite

    Surveillez si la mémoire augmente continuellement même sans activité.

  4. Adapter l’offre

    Augmentez la RAM seulement lorsque la consommation normale et optimisée dépasse encore la limite.

Afficher la mémoire utilisée (Node.js)

setInterval(() => {
  const mb = Math.round(process.memoryUsage().rss / 1048576);
  console.log('memory rss=' + mb + ' MB');
}, 60000);

Afficher le pic de mémoire (Python)

import resource

peak_mb = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss // 1024
print(f"peak memory: {peak_mb} MB")

Comprendre le code 137

Le code 137 vaut 128 + 9 : le processus a reçu le signal 9 (SIGKILL) et n’a pas pu se fermer proprement. Sur ACLClouds, la mémoire d’un bot est plafonnée à la RAM de son offre, sans swap. Quand le processus dépasse ce plafond, le noyau Linux le tue aussitôt, sans lui laisser le temps d’écrire une erreur : la dernière ligne de la console est souvent Killed, ou rien du tout.

La console affiche alors l’état « Planté », le « Dernier code de sortie » et la carte « Diagnostic du plantage » avec le motif « Mémoire insuffisante ». La plateforme relance le bot automatiquement, jusqu’à 3 démarrages d’affilée ; s’il retombe à chaque fois, il reste planté jusqu’à votre intervention. Un fonctionnement de 60 secondes ou plus remet ce compteur à zéro.

Mesurer et réduire la mémoire

Sur la page du bot, la ligne « Mémoire » indique la consommation actuelle par rapport à la limite de l’offre. Relevez-la juste après le démarrage, puis après quelques heures : une valeur qui monte sans jamais redescendre alors que le bot ne fait rien signale une fuite. Pour savoir quelle partie du code consomme, écrivez la mémoire dans la console à intervalle régulier avec l’un des extraits ci-dessous.

  • discord.js : limitez les caches avec makeCache et sweepers, et ne demandez que les intents réellement utilisés.
  • discord.py : baissez max_messages et passez chunk_guilds_at_startup=False si vous n’avez pas besoin de la liste complète des membres.

Questions fréquentes

Que signifie FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory ?

Node.js a atteint la limite de son tas JavaScript avant celle du conteneur ; le diagnostic indique là aussi « Mémoire insuffisante ». Cherchez d’abord ce qui grossit : un cache ou un tableau jamais vidé. Vous pouvez aussi fixer le tas un peu sous la RAM de l’offre dans la commande de démarrage, par exemple node --max-old-space-size=256 index.js. La variable NODE_OPTIONS est réservée au système et ne peut pas être ajoutée dans « Démarrage ».

Pourquoi MemoryError ou Killed sur un bot Python ?

MemoryError est levée par Python quand une allocation échoue ; Killed vient du système, qui a arrêté le processus. Dans les deux cas, le bot a demandé plus de mémoire que l’offre n’en donne. Les causes habituelles : un gros fichier lu d’un seul bloc, une bibliothèque lourde comme pandas chargée pour une seule fonction, ou une liste qui grandit à chaque message.

Faut-il passer à une offre supérieure ?

Seulement si la consommation reste proche de la limite une fois le code optimisé. L’offre gratuite donne 315 Mo de RAM : c’est suffisant pour un bot simple, pas pour un bot qui garde en cache les membres de nombreux serveurs ou qui diffuse de la musique sur plusieurs salons à la fois.