OOM killer (Out-Of-Memory Killer)

Bonjour à tous. j'ai mon server vps sous debian 11 qui plante régulièrement avec cette erreur: OOM killer (Out-Of-Memory Killer) .
Quelqu'un de la communauté pourrais m'aider a comprendre d'où viens le problème et comment le résoudre.

Pour le moment j'ai fait < top u> j'ai constaté que l utilisateur www-data et mysql consommait la majeur partie de la mémoire vive. ) 80%
J'aimerai bien savoir comment associé le pid que je vois au site et a la base incriminé pour intervenir dessus si le problème vient de la.

Merci d'avance pour vos reponses et surtout votre aide.

Pièce jointe 651224

Bonjour,

C'est nouveau le plantage récurrent ?

SInon et si je ne me trompe pas, je vois 1 seul proco, 2 Go de RAM et 0 swap >.<

Perso ça fait un peu light >.<

hth,

Le plantage est récurent depuis plusieurs semaine, mais j'essaye de trouver la solution par moi même. Malheureusement j'y passe beaucoup de temps sans avancé.
le problème c'est amplifier cette dernière semaine mais j'ai rien fait de spéciale. y'a juste 3 sites qui on peu Traffic qui tourne pour 1 copine et copain.
y'a 15j on ma donner un exercice a faire avec Graphana et Prometheus mais je pense pas que le problème vienne de la j'ai juste installer les logiciels.
Voila pour les derniers Event

Bonjour,
En bas du screenshot, on voit bien que grafana tourne, il devrait en être de même pour prometheus.
Si l'exercice est fini, commencez par désinstaller tout ce qui avait servi à celui-ci.

oomkiller c'est quand swap et mémoire sont saturés.
Déjà qu'il n'y a pas de swap, on va vite saturer la mémoire.
Pourquoi n'y a-t-il pas de swap ?

hth,

Bonjour,
En effet il y'avait pas de swapp activé. Erreur de débutant je n'ai pas fait cette vérification, dans mes cours et mes tutos. J'en est profiter pour regarder a quoi il servait et comment ca fonctionne. Je viens de l'activé en créant un fichier de 2go apparemment il n'est pas recommande de créer un fichier swap ni une partition swap sur un SSD. La raison évoqué: (Le SSD est limité en écritures, c'est a dire qu'ils s’abîment en fonction de la quantité de fichier que vous écrivez dessus.)

Mon exercice sur prometheus et graphana n'est pas terminer je dois ecrire un script shell pour récupérer la base json et l'intégrer a prometheus. Je bloque un peu sur le sujet. j'ai aussi des exercice sur les logs apache php et mysql.

Tu pourrais me mettre sur d'autre piste pour mieux gérer mes ressources serveur, éviter l'erreur OOM killer ?

Bonjour,

Effectivement, du swap sur un SSD c'est pas la bonne idée >.<, ça m'avait échappé.

Code:

---

cat /sys/block/sda/queue/rotational

---

retourne 0 pour un SSD et 1 pour SATA, SCSI
si ton disque est bien en sda.

Il faut regarder dans les logs qui provoque le oom killer.
Pareil, mariadb peut-être configuré de différentes façons suivant la charge prévue.
Tout est normalement décrit dans le fichier de configuration de mariadb.

Si l'exercice n'est pas fini, au lieu de désinstaller, stop les services.
Comme ça pas de pertes de données le temps de tester si c'est ça qui déclenche le oom.

Globalement les logs sont assez verbeux pour cerner un défaut, disfonctionnement.

hth,

Hello,

Le fameux oom killer.

T'as deux solutions:
1. Augmenter ta RAM
2. Limiter la RAM utilisée par un process (via ses fichiers de configuration ou, encore mieux, via une directive systemd du service (MemoryLimit de mémoire).

La deuxième option va te causer des timeouts sympathiques, on peut limite considérer ça comme un down de production.

Pour moi, ou bien tu augmentes ta RAM, ou bien tu déportes certains services sur un autre serveur. Ou bien comme le dit Ti-slackeux tu down certains services.

EDIT: si tu veux check quel process utilise ta RAM et cause l'oom killer, perso j'utiliserai la commande dstat et tu laisse tourner dans un screen jusqu'au prochain oomkiller

Citation:

---

Envoyé par tabouret

Hello,

EDIT: si tu veux check quel process utilise ta RAM et cause l'oom killer, perso j'utiliserai la commande dstat et tu laisse tourner dans un screen jusqu'au prochain oomkiller

---

Bien vu le coup du dstat ;)
Je ne connaissais pas et du coup c'est dispo sur mon serveur.
Merci ;)

Citation:

---

Envoyé par Ti-Slackeux

...

---

Je viens de supprimer le swap que j'avais fait et stopper les services jusqu'à ce que je me remette sur mon exo.
Pour les logs j'ai vraiment du mal a les interprétés et j'ai des exercices dessus a faire mais j'ai pas récupérer les cours. Tu aurais quelques liens a me donner pour commencer a apprendre cette partie efficacement ?

Citation:

---

Envoyé par tabouret

...

---

Je viens d'augmenter la ram du serveur je vais enrichir OVH de 2,36 € de plus :)
Pour ma culture personnel est t'il possible de remonter a la source avec la commande htop ?
Je m'explique je vois les PID associé a l'utilisateur www-data qui consomme le plus de ressource.
Je suppose que le PID doit correspondre au processus qui est le site internet en cause de cette consommation ?
La ou je bloque c'est de savoir a quoi correspond le PID si je le kill au risque de perdre des données c'est pas très pas bien .

Citation:

---

Envoyé par Meria_xbase

Je viens de supprimer le swap que j'avais fait et stopper les services jusqu'à ce que je me remette sur mon exo.
Pour les logs j'ai vraiment du mal a les interprétés et j'ai des exercices dessus a faire mais j'ai pas récupérer les cours. Tu aurais quelques liens a me donner pour commencer a apprendre cette partie efficacement ?

---

Bonjour,

Chez ovh, par défaut c'est de la debian et c'est aussi avec systemd.
Du coup la commande

Code:

---

journalctl

---

est faite pour les logs sauce systemd.
les logs se trouvent en /var/log/ et les sous-répertoires comme le répertoire apache2 dédié à apache évidemment ^^".

Avec htop, tu as la possibilité de filtrer l'affichage (F4) pour plus de clarté.
Normalement, la définition des sites se trouve en /etc/apache2/sites-available et les sites actif en /etc/apache2/sites-enabled.
Pour stopper un site avec apache, plutôt que de prendre le risque de tuer un process au pif, il vaut mieux utiliser la commande

Code:

---

a2dissite <Le site à stopper>

---

et relancer apache par la suite.

hth,

Citation:

---

Envoyé par Meria_xbase

La ou je bloque c'est de savoir a quoi correspond le PID si je le kill au risque de perdre des données c'est pas très pas bien .

---

Y'a 3 règles:
1. Ne JAMAIS kill un processus apache en production
2. Ne JAMAIS kill un processus apache en production
3. Ne JAMAIS kill un processus apache en production

De toute façon il va re spawn dans la seconde.

Si tu as vraiment besoin de reboot le truc, systemctl restart apache2.