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

Respostas:

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