Question Qu'est-ce qui a tué mon processus et pourquoi?


Mon application s'exécute en tant que processus d'arrière-plan sous Linux. Il est actuellement démarré sur la ligne de commande dans une fenêtre de terminal.

Récemment, un utilisateur exécutait l'application pendant un moment et il est mort mystérieusement. Le texte:

Tué

était sur le terminal. Cela s'est passé deux fois. J'ai demandé si quelqu'un dans un autre terminal utilisait la commande kill pour tuer le processus? Non.

Sous quelles conditions Linux déciderait-il de tuer mon processus? Je crois que le shell a été "tué" parce que le processus est mort après avoir reçu le signal kill (9). Si Linux envoyait le signal de suppression, devrait-il y avoir un message dans un journal système quelque part qui explique pourquoi il a été tué?


463
2018-04-07 17:07


origine


Réponses:


Si l'utilisateur ou l'administrateur système n'a pas tué le programme que le noyau peut avoir. Le noyau ne ferait que tuer un processus dans des circonstances exceptionnelles telles que le manque de ressources extrêmes (pensez à épuiser mem + swap).


310
2018-04-07 17:23



Essayer:

dmesg -T| grep -E -i -B100 'killed process'

-B100 signifie le nombre de lignes avant la mort.

Omettre -T sur Mac OS.


169
2017-12-19 02:59



Cela ressemble à un bon article sur le sujet: Apprivoiser le tueur d'OOM.

L'essentiel est que Linux surcharges 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 qu'il demande. Le processus obtiendra une utilisation exclusive de la mémoire qu'il a allouée lorsqu'il l'utilise réellement, et non lorsqu'il le demande. Cela rend l'allocation rapide et peut vous permettre de "tricher" et d'allouer plus de mémoire que vous 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 en allouant de la mémoire qu'il n'a pas, et devra tuer un processus pour en libérer un peu. 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 gourmands sont moins sûrs) et quelques autres facteurs, dont une valeur que vous pouvez ajuster susceptible d'être tué. Tout est décrit plus en détail dans l'article.

Edit: Et voici un autre article cela explique assez bien comment un processus est choisi (annoté avec des exemples de code du noyau). La grande chose à ce sujet est qu’il inclut des commentaires sur le raisonnement derrière les différents badness() règles.


151
2018-04-07 17:51



Laissez-moi d'abord expliquer quand et pourquoi OOMKiller est invoqué?

Supposons que vous ayez 512 RAM + 1Go de mémoire d'échange. Donc, en théorie, votre processeur a accès à un total de 1,5 Go de mémoire virtuelle.

Maintenant, pendant un certain 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.

Maintenant, disons que n'importe quel processus a demandé une grande quantité de mémoire au noyau. Le noyau vérifie la mémoire disponible et constate qu'il n'y a aucun moyen d'allouer plus de mémoire à votre processus. Donc, il va essayer de libérer de la mémoire appelant / invoquant OOMKiller (http://linux-mm.org/OOM).

OOMKiller a son propre algorithme pour évaluer le rang pour chaque processus. Généralement, quel processus utilise plus de mémoire devient la victime à tuer.

Où puis-je trouver les journaux d'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:

  1. Augmenter la mémoire (ne pas échanger)
  2. Trouvez les fuites de mémoire dans votre programme et corrigez-les
  3. Limiter la mémoire que tout processus peut consommer (par exemple, la mémoire JVM peut être restreinte à l'aide de JAVA_OPTS)
  4. Voir les journaux et google :)

32
2018-04-05 00:36



C'est le Linux Gestionnaire de mémoire insuffisante (MOO). Votre processus a été sélectionné pour 'méchanceté'- une combinaison de caractère récent, de taille résidente (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

12
2017-07-20 12:56



Comme dwc et Adam Jaskiewicz l'ont déclaré, le coupable est probablement le tueur OOM. Cependant, la question suivante qui suit est: Comment puis-je empêcher cela?

Il y a plusieurs façons:

  1. Donnez à votre système plus de RAM si vous le pouvez (facile si c'est une VM)
  2. Assurez-vous que le tueur OOM choisit un processus différent.
  3. Désactiver le tueur de MOO
  4. Choisissez une distribution Linux qui est livrée avec le OOM Killer désactivé.

J'ai trouvé (2) particulièrement facile à mettre en œuvre, grâce à Cet article.


11
2018-01-28 19:01



Un outil tel que systemtap (ou un traceur) peut surveiller la logique et le rapport de transmission du signal du noyau. 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 filtrage if bloc dans ce script peut être ajusté au goût, ou éliminé pour suivre le trafic du signal à l'échelle du système. Les causes peuvent être isolées davantage en collectant des backtraces (ajouter un print_backtrace() et / ou print_ubacktrace() à la sonde, respectivement pour le noyau et l'espace utilisateur).


7
2018-02-25 17:59



le Module PAM pour limiter les ressources causé exactement les résultats que vous avez décrits: Mon processus est mort mystérieusement avec le texte Tué sur la fenêtre de la console. Aucune sortie de journal, ni dans syslog ni dans kern.log. le Haut programme m'a aidé à découvrir que exactement après une minute d'utilisation du processeur, mon processus est tué.


6
2018-04-26 19:20



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 la demande de ressource dans la file d'attente, les processus seront supprimés. fuyez. Il n'envoie pas toujours un email quand il le fait, selon sa configuration.

Une solution dans ce cas consiste à trouver une file d'attente avec des ressources plus importantes ou à définir des besoins en ressources plus importants dans la soumission.

Vous pouvez également vouloir revoir man ulimit

Bien que je ne me souvienne pas ulimit résultant en Killed ça fait un moment que j'en avais besoin.


4
2018-03-03 07:07



Nous avons eu des problèmes récurrents sous Linux sur un site client (Red Hat, je pense), avec OOMKiller (tueur hors mémoire) tuant à la fois notre application principale (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 d'échouer faute de ressources. Ni l'application ni sa base de données n'a de problèmes avec les fuites de mémoire (ou toute autre fuite de ressources).

Je ne suis pas un expert Linux, mais j'ai plutôt rassemblé son algorithme pour décider quand tuer quelque chose et ce qu'il faut tuer est complexe. En outre, on m'a dit (je ne peux pas parler de l'exactitude de ceci) que OOMKiller est cuit dans le noyau et vous ne pouvez pas simplement ne pas l'exécuter.


2
2018-04-07 17:44