Qu'est-ce qui a tué mon processus et pourquoi?
Mon application s'exécute en arrière-plan sous Linux. Il est actuellement démarré en ligne de commande dans une fenêtre de terminal.
Récemment, un utilisateur exécutait l'application pendant un certain temps et celle-ci est morte mystérieusement. Le texte:
Tué
était sur le terminal. C'est arrivé deux fois. J'ai demandé si quelqu'un d'un autre terminal utilisait la commande kill pour tuer le processus? Non.
Dans quelles conditions Linux déciderait-il de tuer mon processus? Je crois que Shell a affiché "tué" car le processus est mort après la réception du signal kill (9). Si Linux envoie le signal de destruction, devrait-il y avoir un message dans un journal système quelque part qui explique pourquoi il a été tué?
Si l'utilisateur ou l'administrateur système n'a pas tué le programme du noyau. Le noyau ne tuerait un processus que dans des circonstances exceptionnelles, telles qu'une privation extrême de ressources (pensez à l'épuisement mem + swap).
Essayer:
dmesg -T| grep -E -i -B100 'killed process'
Où -B100 représente le nombre de lignes avant la mise à mort.
Omettre -T sur Mac OS.
Cela ressemble à un bon article sur le sujet: Apprivoiser le tueur OOM .
L’essentiel est que Linux surcharge la mémoire. Quand un processus demande plus d’espace, Linux lui donne cet espace, même s’il est revendiqué par un autre processus, en supposant que personne n’utilise réellement toute la mémoire demandée. Le processus obtiendra une utilisation exclusive de la mémoire allouée lorsqu'il l'utilisera réellement, pas lorsqu'il le demandera. Cela rend l'allocation rapide et peut vous permettre de "tricher" et d'allouer plus de mémoire que vous n'en avez réellement. Cependant, une fois que les processus commenceront à utiliser cette mémoire, Linux pourrait se rendre compte qu'il a été trop généreux dans l'allocation de mémoire qu'il ne possède pas et qu'il va falloir tuer un processus pour en libérer une partie. Le processus à tuer est basé sur un score prenant en compte le temps d'exécution (les processus longs sont plus sûrs), l'utilisation de la mémoire (les processus gloutons sont moins sûrs) et quelques autres facteurs, y compris une valeur que vous pouvez ajuster pour réduire les processus. susceptible d'être tué. Tout est décrit dans l'article de manière beaucoup plus détaillée.
Edit: Et voici un autre article qui explique assez bien comment un processus est choisi (annoté avec quelques exemples de code du noyau). Le point positif à ce sujet est qu’il inclut des commentaires sur le raisonnement derrière les diverses règles badness().
Laissez-moi d'abord expliquer quand et pourquoi OOMKiller est invoqué?
Disons que vous avez 512 RAM + 1GB Swap memory. Donc, en théorie, votre processeur a accès à un total de 1,5 Go de mémoire virtuelle.
Depuis quelque temps, tout fonctionne correctement avec 1,5 Go de mémoire totale. Mais soudainement (ou progressivement), votre système a commencé à consommer de plus en plus de mémoire et a atteint environ 95% de la mémoire totale utilisée.
Supposons maintenant que tout processus a demandé une grande quantité de mémoire au noyau. Le noyau vérifie la mémoire disponible et constate qu’il n’ya aucun moyen d’allouer plus de mémoire à votre processus. Donc, il va essayer de libérer de la mémoire en appelant/invoquant OOMKiller ( http://linux-mm.org/OOM ).
OOMKiller a son propre algorithme pour marquer le rang pour chaque processus. Généralement, le processus qui utilise plus de mémoire devient la victime à tuer.
Où puis-je trouver les journaux de OOMKiller?
Généralement, dans le répertoire/var/log. /Var/log/kern.log ou/var/log/dmesg
J'espère que ceci vous aidera.
Quelques solutions typiques:
- Augmenter la mémoire (pas échanger)
- Trouvez les fuites de mémoire dans votre programme et corrigez-les
- Limiter la mémoire que tout processus peut consommer (par exemple, la mémoire de la machine virtuelle Java peut être restreinte à l'aide de Java_OPTS)
- Voir les journaux et google :)
Il s’agit du gestionnaire Linux out of memory (OOM). Votre processus a été sélectionné en raison de 'badness' - une combinaison de la date récente, de la taille du résident (mémoire utilisée, plutôt que simplement allouée) et d'autres facteurs.
Sudo journalctl -xb
Vous verrez un message comme:
Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU 0: hi: 186, btch: 31 usd: 30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
active_file:722 inactive_file:4126 isolated_file:0
unevictable:0 dirty:5 writeback:0 unstable:0
free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
mapped:792 shmem:12802 pagetables:1651 bounce:0
free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [ 241] 0 241 13581 1610 26 0 0 systemd-journal
Jul 20 11:05:00 someapp kernel: [ 246] 0 246 10494 133 22 0 -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [ 264] 0 264 29174 121 26 0 -1000 auditd
Jul 20 11:05:00 someapp kernel: [ 342] 0 342 94449 466 67 0 0 NetworkManager
Jul 20 11:05:00 someapp kernel: [ 346] 0 346 137495 3125 88 0 0 tuned
Jul 20 11:05:00 someapp kernel: [ 348] 0 348 79595 726 60 0 0 rsyslogd
Jul 20 11:05:00 someapp kernel: [ 353] 70 353 6986 72 19 0 0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [ 362] 70 362 6986 58 18 0 0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [ 378] 0 378 1621 25 8 0 0 iprinit
Jul 20 11:05:00 someapp kernel: [ 380] 0 380 1621 26 9 0 0 iprupdate
Jul 20 11:05:00 someapp kernel: [ 384] 81 384 6676 142 18 0 -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [ 385] 0 385 8671 83 21 0 0 systemd-logind
Jul 20 11:05:00 someapp kernel: [ 386] 0 386 31573 153 15 0 0 crond
Jul 20 11:05:00 someapp kernel: [ 391] 999 391 128531 2440 48 0 0 polkitd
Jul 20 11:05:00 someapp kernel: [ 400] 0 400 9781 23 8 0 0 iprdump
Jul 20 11:05:00 someapp kernel: [ 419] 0 419 27501 32 10 0 0 agetty
Jul 20 11:05:00 someapp kernel: [ 855] 0 855 22883 258 43 0 0 master
Jul 20 11:05:00 someapp kernel: [ 862] 89 862 22926 254 44 0 0 qmgr
Jul 20 11:05:00 someapp kernel: [23631] 0 23631 20698 211 43 0 -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884] 0 12884 81885 3754 80 0 0 firewalld
Jul 20 11:05:00 someapp kernel: [18130] 0 18130 33359 291 65 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18132] 1000 18132 33791 748 64 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18133] 1000 18133 28867 122 13 0 0 bash
Jul 20 11:05:00 someapp kernel: [18428] 99 18428 208627 42909 151 0 0 node
Jul 20 11:05:00 someapp kernel: [18486] 89 18486 22909 250 46 0 0 pickup
Jul 20 11:05:00 someapp kernel: [18515] 1000 18515 352905 141851 470 0 0 npm
Jul 20 11:05:00 someapp kernel: [18520] 0 18520 33359 291 66 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18522] 1000 18522 33359 294 64 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18523] 1000 18523 28866 115 12 0 0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB
Comme Dwc et Adam Jaskiewicz l'ont déclaré, le coupable est probablement le tueur de MOO. Cependant, la question suivante est la suivante: comment puis-je empêcher cela?
Il y a plusieurs façons:
- Donnez plus à votre système RAM si vous le pouvez (facile si c'est une machine virtuelle)
- Assurez-vous que le tueur OOM choisit un processus différent.
- Désactiver le tueur de MOO
- Choisissez une distribution Linux livrée avec le MOO Killer désactivé.
J'ai trouvé (2) particulièrement facile à mettre en œuvre, grâce à cet article .
Le module PAM pour limiter les ressources a provoqué exactement les résultats que vous avez décrits: Mon processus est mort mystérieusement avec le texte Killed dans la fenêtre de la console. Aucune sortie de journal, ni dans syslog ni dans kern.log. Le programme top m'a aidé à découvrir que c'est exactement après une minute d'utilisation du processeur que mon processus a été tué.
Un outil tel que systemtap (ou un traceur) peut surveiller la logique de transmission du signal du noyau et générer des rapports. Par exemple, https://sourceware.org/systemtap/examples/process/sigmon.stp
# stap .../sigmon.stp -x 31994 SIGKILL
SPID SNAME RPID RNAME SIGNUM SIGNAME
5609 bash 31994 find 9 SIGKILL
Le bloc de filtrage if de ce script peut être ajusté à votre goût ou éliminé pour suivre le trafic des signaux à l’échelle du système. Les causes peuvent être encore isolées en collectant des traces (ajouter une print_backtrace() et/ou print_ubacktrace() à la sonde, pour le noyau et l'espace utilisateur respectivement).
Dans un environnement lsf (interactif ou autre), si l'application dépasse l'utilisation de la mémoire au-delà d'un seuil prédéfini par les administrateurs de la file d'attente ou si la demande de ressource est soumise à la file d'attente, les processus seront tués afin que les autres utilisateurs ne soient pas victimes d'un potentiel fuyez. Il n'envoie pas toujours d'e-mail lorsqu'il le fait, en fonction de la configuration.
Une solution dans ce cas consiste à trouver une file d'attente avec des ressources plus importantes ou à définir des exigences de ressources plus importantes dans la soumission.
Vous voudrez peut-être aussi passer en revue man ulimit
Bien que je ne me souvienne pas de ulimit ayant pour résultat Killed, cela fait longtemps que je n’en ai pas besoin.
Nous avons eu des problèmes récurrents sous Linux sur un site client (Red Hat, je pense), OOMKiller (tueur de mémoire insuffisante) a tué notre application principale (c’est-à-dire la raison pour laquelle le serveur existe) et ses processus de base de données.
Dans chaque cas, OOMKiller a simplement décidé que les processus utilisaient beaucoup de ressources… la machine n’était même pas sur le point de tomber en panne par manque de ressources. Ni l'application ni sa base de données n'ont de problèmes de mémoire (ou de toute autre fuite de ressource).
Je ne suis pas un expert en Linux, mais j'ai plutôt rassemblé son algorithme pour décider quand tuer quelque chose et quoi tuer est complexe. De plus, on m'a dit (je ne peux pas parler de l'exactitude) que OOMKiller est intégré au noyau et que vous ne pouvez pas simplement ne pas l'exécuter.
Résolution de ce problème par augmentation de la taille de l'échange :
https://askubuntu.com/questions/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04
J'ai rencontré ce problème récemment. Enfin, j'ai découvert que mes processus avaient été supprimés juste après l'appel automatique de la mise à jour Opensuse zypper. Désactiver la mise à jour de zypper a résolu mon problème.
L'utilisateur a la possibilité de tuer ses propres programmes, en utilisant kill ou Control + C, mais j'ai l'impression que ce n'est pas ce qui s'est passé et qu'il s'est plaint à vous.
root a la capacité de tuer des programmes bien sûr, mais si quelqu'un a la racine sur votre machine et tue des choses, vous avez de plus gros problèmes.
Si vous n'êtes pas l'administrateur système, il se peut qu'il ait défini des quotas d'utilisation du processeur, de la mémoire vive, du disque dur et de la mort automatique des processus qui les dépassent.
Autre que ces suppositions, je ne suis pas sûr sans plus d'informations sur le programme.
Dans mon cas, cela se passait avec un travailleur de la file d'attente Laravel. Les journaux système ne mentionnant aucun meurtre, j'ai donc cherché plus loin et il s'est avéré que le travailleur se tuait tout seul à cause d'un travail dépassant la limite de mémoire (définie à 128 Mo par défaut).
L'exécution du programme de traitement de file d'attente avec --timeout=600 et --memory=1024 a résolu le problème pour moi.