A maioria dos comandos de execução longa foram instantaneamente mortos no Amazon EC2 (Ubuntu 10.04)

26

Ao executar qualquer tipo de comando de longa duração no terminal, o programa morre instantaneamente e o terminal gera o texto Killed.

Alguma dica? Talvez haja um arquivo de log com dados explicando por que os comandos estão sendo mortos?

Atualizar

Aqui está um trecho dmesgque, esperançosamente, deve esclarecer o que está causando o problema. Outra observação que pode ser útil é que esta é uma instância do 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
fonte

Muito útil, só tinha o mesmo problema

— Cookies

36

Você deve conseguir descobrir o que matou seu processo observando a saída do dmesgcomando; ou nos ficheiros de registo /var/log/kern.log, /var/log/messagesou /var/log/syslog.

Há várias coisas que podem fazer com que um processo seja sumariamente eliminado:

Se exceder o limite máximo para vários tipos de uso de memória ou CPU que você pode examinar usando ulimit -H -a
Se o sistema estiver com pouca memória virtual, os processos podem ser mortos pelo oom-killer do kernel para liberar memória (no seu caso, provavelmente não é isso)
Se o sistema tiver o SELinux e / ou o PaX / grsecurity instalado, um processo poderá ser interrompido se tentar fazer algo que não é permitido pela política de segurança ou se tentar executar código auto-modificado.

Os logs ou dmesg devem dizer por que o processo foi encerrado.

— Heath
fonte

Obrigado pela sua resposta! Acabei de verificar os arquivos de log que você mencionou, mas não consigo encontrar muitos dados úteis. Confira a atualização da minha resposta para ver de relance.

— Dan Loewenherz

3

Sim, você está sendo mordido pelo assassino; o que significa que você ficou sem memória. Tente adicionar algum espaço de troca à sua instância (mesmo algumas centenas de megas de troca podem ajudar muito em uma situação de pouca memória).

— Heath

Para outros, que se perguntou como adicionar swap para uma instância EC2, esta resposta me ajudou (após SSHing no exemplo): stackoverflow.com/a/17173973/4900327

— Abhishek Divekar

10

Os logs que você publicou como na atualização indicam que o sistema está ficando sem memória e o killer do OOM está sendo chamado para interromper os processos, a fim de manter a memória livre quando "tudo mais falhar". O algoritmo de seleção para o OOM killer pode ter como alvo favorável seus processos de "longa execução". Veja a página vinculada para uma descrição do algoritmo de seleção.

A solução óbvia é mais memória, mas você pode estar ficando sem memória devido a um vazamento de memória em algum lugar e a adição de mais memória provavelmente atrasaria o invocador do OOM, se esse fosse o caso. Verifique sua tabela de processos em busca de processos usando mais memória com sua ferramenta favorita (parte superior, ps, etc.) e vá a partir daí.

— rthomson
fonte

O OOM killer tem uma preferência definitiva por processos de longa duração e baixa atividade. Tê-lo morto sshd em um servidor de produção torna a depuração complicada.

— Mfarver 15/05

O Sshd ajusta sua própria pontuação / proc / pid / oom_adj para que não possa ser morto pelo oom killer (antes de matar todo o resto).

— Yaplik 17/05/11

@yaplik Parece que isso não se aplica mais às distribuições recentes. Como os processos filhos herdam o valor de oom_adj, um usuário mal-intencionado pode causar um DoS consumindo toda a memória sem que seus processos sejam mortos pelo killer do OOM.

— Ikso 17/05

4

Como já foi explicado por outras pessoas, você está ficando sem memória, portanto, o exterminador de memória é acionado e mata algum processo.

Você pode corrigir isso fazendo:

a) atualize sua máquina ec2 para uma mais poderosa, 'instância pequena' tem 2,5x mais memória (1,7 GB) do que 'micro instância' (0,64 GB), custa dinheiro adicional

b) adição de partição swap - adicione unidade adicional EBS, mkswap /dev/sdx, swapon /dev/sdx, os custos de armazenamento EBS e taxas de IO

c) adição de arquivo de troca - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, custa taxas de IO e espaço livre na raiz EBS

O c) deve ser suficiente, mas lembre-se de que a microinstância não deve executar tarefas de uso intensivo de CPU de longa duração devido a limites de CPU (apenas rajadas curtas permitidas).

— yaplik
fonte

3

Eu tive o mesmo problema. Meus processos estavam sendo mortos.

Eu descobri que a AMI do Ubuntu que eu estava usando não tinha um espaço de troca configurado. Quando a memória estiver cheia e não houver espaço de troca disponível, o kernel começará imprevisivelmente a matar processos para se proteger. O espaço de troca impede isso. (Esse problema é especialmente relevante para a instância Micro por causa dos pequenos 613 MB de memória.)

Para verificar se você possui um espaço de troca configurado, digite: swapon -s

Configure o espaço de troca: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

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

— Delicioso
fonte

Trabalhou para mim! Meu dmesg continha apenas muitos "select proccess_name to kill" um após o outro e eu não tinha / var / log / messages ou quaisquer logs úteis, mas executar "free -h" mostrava que quase não havia mais memória. Muito Obrigado!

— divieira 14/09

1

O log diz que você está ficando sem memória de troca / cache.

    14 de maio 20:29:15 kernel ip-10-112-33-63: [11144050.272240] 0 páginas no cache de troca
    14 de maio 20:29:15 kernel ip-10-112-33-63: [11144050.272242] Estatísticas do cache de swap: adicione 0, exclua 0, encontre 0/0
    14 de maio 20:29:15 Kernel ip-10-112-33-63: [11144050.272243] Troca grátis = 0kB
    14 de maio 20:29:15 kernel ip-10-112-33-63: [11144050.272244] Troca total = 0kB

Você pode dividir o trabalho / processo em execução em lotes? Talvez você possa tentar executá-lo isoladamente depois de interromper os outros processos?

— Mecânico de Software
fonte