La plupart des commandes de longue durée tuées instantanément sur Amazon EC2 (Ubuntu 10.04)

26

Lors de l'exécution de toute sorte de commande de longue durée dans le terminal, le programme meurt instantanément et le terminal sort le texte Killed.

Des pointeurs? Peut-être existe-t-il un fichier journal contenant des données expliquant pourquoi les commandes sont tuées?

Mise à jour

Voici un extrait de ce dmesgqui devrait, espérons-le, éclairer la cause du problème. Une autre remarque qui pourrait être utile est qu'il s'agit d'une instance Amazon EC2.

May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184209] Call Trace:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184218]  [<c01e49ea>] dump_header+0x7a/0xb0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184221]  [<c01e4a7c>] oom_kill_process+0x5c/0x160
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184224]  [<c01e4fe9>] ? select_bad_process+0xa9/0xe0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184227]  [<c01e5071>] __out_of_memory+0x51/0xb0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184229]  [<c01e5128>] out_of_memory+0x58/0xd0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184232]  [<c01e7f16>] __alloc_pages_slowpath+0x416/0x4b0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184235]  [<c01e811f>] __alloc_pages_nodemask+0x16f/0x1c0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184238]  [<c01ea2ca>] __do_page_cache_readahead+0xea/0x210
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184241]  [<c01ea416>] ra_submit+0x26/0x30
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184244]  [<c01e3aef>] filemap_fault+0x3cf/0x400
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184247]  [<c02329ad>] ? core_sys_select+0x19d/0x240
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184252]  [<c01fb65c>] __do_fault+0x4c/0x5e0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184254]  [<c01e4161>] ? generic_file_aio_write+0xa1/0xc0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184257]  [<c01fd60b>] handle_mm_fault+0x19b/0x510
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184262]  [<c05f80d6>] do_page_fault+0x146/0x440
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184265]  [<c0232c62>] ? sys_select+0x42/0xc0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184268]  [<c05f7f90>] ? do_page_fault+0x0/0x440
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184270]  [<c05f53c7>] error_code+0x73/0x78
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184274]  [<c05f007b>] ? setup_local_APIC+0xce/0x33e
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272161]  [<c05f0000>] ? setup_local_APIC+0x53/0x33e
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272163] Mem-Info:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272164] DMA per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272166] CPU    0: hi:    0, btch:   1 usd:   0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272168] Normal per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272169] CPU    0: hi:  186, btch:  31 usd:  50
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272171] HighMem per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272172] CPU    0: hi:  186, btch:  31 usd:  30
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272176] active_anon:204223 inactive_anon:204177 isolated_anon:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272177]  active_file:47 inactive_file:141 isolated_file:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272178]  unevictable:0 dirty:0 writeback:0 unstable:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272179]  free:10375 slab_reclaimable:1650 slab_unreclaimable:1856
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272180]  mapped:2127 shmem:3918 pagetables:1812 bounce:0May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272186] DMA free:6744kB min:72kB low:88kB high:108kB active_anon:300kB inactive_anon:308kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15812kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272190] lowmem_reserve[]: 0 702 1670 1670May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272197] Normal free:34256kB min:3352kB low:4188kB high:5028kB active_anon:317736kB inactive_anon:317308kB active_file:144kB inactive_file:16kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:719320kB mlocked:0kB dirty:4kB writeback:0kB mapped:32kB shmem:0kB slab_reclaimable:6592kB slab_unreclaimable:7424kB kernel_stack:2592kB pagetables:7248kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:571 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272201] lowmem_reserve[]: 0 0 7747 7747May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272207] HighMem free:500kB min:512kB low:1668kB high:2824kB active_anon:498856kB inactive_anon:499092kB active_file:44kB inactive_file:548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:991620kB mlocked:0kB dirty:0kB writeback:0kB mapped:8472kB shmem:15672kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:430 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272211] lowmem_reserve[]: 0 0 0 0May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272215] DMA: 10*4kB 22*8kB 38*16kB 33*32kB 16*64kB 10*128kB 4*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 6744kBMay 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272223] Normal: 476*4kB 1396*8kB 676*16kB 206*32kB 23*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 34256kBMay 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272231] HighMem: 1*4kB 2*8kB 28*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 500kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272238] 4108 total pagecache pages
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272240] 0 pages in swap cache
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272242] Swap cache stats: add 0, delete 0, find 0/0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272243] Free swap  = 0kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272244] Total swap = 0kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276842] 435199 pages RAM
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276845] 249858 pages HighMem
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276846] 8771 pages reserved
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276847] 23955 pages shared
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276849] 405696 pages non-shared

ubuntu amazon-ec2 terminal

— Dan Loewenherz
source

Très utile, vient d'avoir le même problème

— Cookie

36

Vous devriez pouvoir découvrir ce qui a tué votre processus en regardant la sortie de la dmesgcommande; ou dans les fichiers journaux /var/log/kern.log, /var/log/messagesou /var/log/syslog.

Il y a un certain nombre de choses qui peuvent entraîner l'arrêt brutal d'un processus:

S'il dépasse le nombre maximal de disques pour différents types d'utilisation de mémoire ou de processeur que vous pouvez examiner à l'aide ulimit -H -a
Si le système manque de mémoire virtuelle, les processus peuvent être tués par le noyau oom-killer pour libérer de la mémoire (dans votre cas, ce n'est probablement pas le cas)
Si le système a SELinux et / ou PaX / grsecurity installé, un processus peut être tué s'il essaie de faire quelque chose qui n'est pas autorisé par la politique de sécurité, ou s'il essaie d'exécuter du code auto-modifié.

Les journaux ou dmesg devraient vous dire pourquoi le processus a été interrompu.

— Bruyère
source

Merci pour votre réponse! Je viens de consulter les fichiers journaux que vous avez mentionnés, mais je n'arrive pas à trouver beaucoup de données utiles. Consultez la mise à jour de ma réponse pour voir un aperçu.

— Dan Loewenherz

3

Oui, vous vous faites mordre par le tueur à gages; ce qui signifie que vous n'avez plus de mémoire. Essayez d'ajouter un espace de swap à votre instance (même quelques centaines de mégas de swap peuvent être très utiles dans une situation de faible mémoire).

— Heath

Pour ceux qui se demandaient comment ajouter un swap à une instance EC2, cette réponse m'a aidé (après SSHing dans l'instance): stackoverflow.com/a/17173973/4900327

— Abhishek Divekar

10

Les journaux que vous avez publiés en tant que mise à jour indiquent que votre système manque de mémoire et que le tueur OOM est invoqué pour tuer les processus afin de maintenir la mémoire libre lorsque "tout le reste échoue". L'algorithme de sélection pour le tueur OOM pourrait viser favorablement vos processus "de longue durée". Voir la page liée pour une description de l'algorithme de sélection.

La solution évidente est plus de mémoire, mais vous risquez de manquer de mémoire en raison d'une fuite de mémoire quelque part et l'ajout de mémoire ne retarderait probablement le tueur OOM que si cela était le cas. Vérifiez votre table de processus pour les processus utilisant le plus de mémoire avec votre outil préféré (top, ps, etc.) et allez-y.

— rthomson
source

Le tueur OOM a une préférence certaine pour les processus de longue durée et de faible activité. Le faire tuer sshd sur un serveur de production rend le débogage délicat.

— mfarver

Sshd ajuste son propre score / proc / pid / oom_adj afin qu'il ne puisse pas être tué par oom killer (avant qu'il ne tue tout le reste).

— yaplik

@yaplik Cela ne semble plus s'appliquer aux distributions récentes. Comme les processus enfants héritent de la valeur de oom_adj, un utilisateur malveillant peut provoquer un DoS en consommant toute la mémoire sans que ses processus soient tués par le tueur OOM.

— ikso

4

Comme déjà expliqué par d'autres, vous manquez de mémoire, donc le tueur de mémoire est déclenché et tue certains processus.

Vous pouvez résoudre ce problème soit:

a) mettez à niveau votre machine ec2 vers une machine plus puissante, «petite instance» a 2,5 fois plus de mémoire (1,7 Go) que «micro instance» (0,64 Go), coûte plus cher

b) l' ajout d'une partition de swap - ajouter disque supplémentaire EBS, mkswap /dev/sdx, swapon /dev/sdx, les coûts de stockage EBS et frais IO

c) l' ajout de fichier d'échange - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, les honoraires facturés IO et espace libre sur la racine EBS

Le c) devrait être suffisant, mais gardez à l'esprit que la micro-instance n'est pas censée exécuter de longues tâches gourmandes en CPU en raison des limites de CPU (seules les courtes rafales sont autorisées).

— yaplik
source

3

J'ai eu le même problème. Mes processus étaient en train d'être tués.

J'ai découvert que l'AMI Ubuntu que j'utilisais n'avait pas d'espace de swap configuré. Lorsque la mémoire est pleine et qu'il n'y a pas d'espace de swap disponible, le noyau commencera de manière imprévisible à tuer les processus pour se protéger. L'espace d'échange empêche cela. (Ce problème est particulièrement pertinent pour l'instance Micro en raison du petit 613 Mo de mémoire.)

Pour vérifier si vous disposez d'un espace de configuration de type d'échange: swapon -s

Configurer l'espace de swap: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

Autres ressources: http://wiki.sysconfig.org.uk/display/howto/Build+your+own+Core+CentOS+5.x+AMI+for+Amazon+EC2

— Délicieux
source

A travaillé pour moi! Mon dmesg ne contenait que de nombreux "select proccess_name to kill" les uns après les autres et je n'avais aucun / var / log / messages ni aucun journal utile, mais l'exécution de "free -h" montrait qu'il ne restait presque plus de mémoire. Merci beaucoup!

— divieira

1

Le journal indique que vous manquez de mémoire swap / cache.

    14 mai 20:29:15 noyau ip-10-112-33-63: [11144050.272240] 0 pages dans le cache de swap
    14 mai 20:29:15 noyau ip-10-112-33-63: [11144050.272242] Swap cache stats: add 0, delete 0, find 0/0
    14 mai 20:29:15 noyau ip-10-112-33-63: [11144050.272243] Échange gratuit = 0 Ko
    14 mai 20:29:15 noyau ip-10-112-33-63: [11144050.272244] Total swap = 0kB

Pouvez-vous diviser le travail / processus que vous exécutez par lots? Vous pouvez peut-être essayer de l'exécuter de manière isolée après avoir arrêté les autres processus?

— Mécanicien logiciel
source