Większość długotrwałych poleceń natychmiast zabijanych na Amazon EC2 (Ubuntu 10.04)

26

Po uruchomieniu dowolnego polecenia długotrwałego w terminalu program natychmiast umiera, a terminal wysyła tekst Killed.

Jakieś wskazówki? Może jest plik dziennika z danymi wyjaśniającymi, dlaczego polecenia są zabijane?

Aktualizacja

Oto fragment dmesgtego, który, mam nadzieję, powinien wyjaśnić, co jest przyczyną problemu. Kolejna uwaga, która może być pomocna, to fakt, że jest to instancja 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
źródło
Bardzo pomocny, właśnie miałem ten sam problem
— Cookie

Odpowiedzi:

36

Powinieneś być w stanie dowiedzieć się, co zabiło twój proces, patrząc na wynik dmesgpolecenia; lub logów /var/log/kern.log, /var/log/messageslub /var/log/syslog.

Istnieje wiele rzeczy, które mogą spowodować, że proces zostanie ostatecznie zabity:

  • Jeśli przekracza twardą ulimit dla różnych rodzajów użycia pamięci lub procesora, które można sprawdzić za pomocą ulimit -H -a
  • Jeśli w systemie jest mało pamięci wirtualnej, procesy mogą zostać zabite przez jądro oom-killer w celu zwolnienia pamięci (w twoim przypadku prawdopodobnie nie jest to)
  • Jeśli w systemie jest zainstalowany SELinux i / lub PaX / grsecurity, proces może zostać zabity, jeśli spróbuje zrobić coś, co nie jest dozwolone przez zasady bezpieczeństwa, lub jeśli spróbuje wykonać sam zmodyfikowany kod.

Dzienniki lub dmesg powinny informować, dlaczego proces został zabity.

— Wrzosowisko
źródło
Dzięki za odpowiedź! Właśnie sprawdziłem pliki dziennika, o których wspomniałeś, ale nie mogę znaleźć zbyt przydatnych danych. Sprawdź aktualizację mojej odpowiedzi, aby zobaczyć rzut oka.
— Dan Loewenherz
3
Tak, przygniata cię zabójca; co oznacza, że ​​zabrakło Ci pamięci. Spróbuj dodać trochę przestrzeni wymiany do instancji (nawet kilkaset megapikseli wymiany może bardzo pomóc w sytuacji braku pamięci).
— Wrzos
Dla innych, którzy zastanawiali się, jak dodać swap do instancji EC2, ta odpowiedź pomogła mi (po SSHing do instancji): stackoverflow.com/a/17173973/4900327
— Abhishek Divekar
10

Dzienniki, które opublikowałeś jako w aktualizacji, wskazują, że w twoim systemie zabrakło pamięci, a OOM jest wywoływany w celu zabicia procesów w celu utrzymania wolnej pamięci, gdy „wszystko inne zawiedzie”. Algorytm wyboru dla zabójcy OOM może być korzystny dla twoich „długotrwałych” procesów. Zobacz połączoną stronę, aby uzyskać opis algorytmu wyboru.

Oczywistym rozwiązaniem jest więcej pamięci, ale może zabraknąć pamięci z powodu wycieku pamięci, a dodanie większej ilości pamięci prawdopodobnie opóźni wywołanie zabójcy OOM, jeśli tak jest. Sprawdź tabelę procesów pod kątem procesów wykorzystujących najwięcej pamięci za pomocą ulubionego narzędzia (top, ps itp.) I stamtąd.

— rthomson
źródło
Zabójca OOM ma określone preferencje dla długotrwałych procesów o niskiej aktywności. Zabicie sshd na serwerze produkcyjnym utrudnia debugowanie.
— mfarver
Sshd dostosowuje swój wynik / proc / pid / oom_adj, aby nie mógł zostać zabity przez oom killera (zanim zabije wszystko inne).
— yaplik
@yaplik Wydaje się, że nie dotyczy to już ostatnich dystrybucji. Ponieważ procesy potomne dziedziczą wartość oom_adj, złośliwy użytkownik może spowodować atak DoS, zużywając całą pamięć bez zabijania procesów przez zabójcę OOM.
— ikso
4

Jak już wyjaśnili inni, zabrakło pamięci, więc zabójca pamięci zostaje uruchomiony i zabija proces.

Możesz to naprawić, wykonując:

a) zaktualizuj swoją maszynę ec2 do bardziej wydajnej, „mała instancja” ma 2,5 razy więcej pamięci (1,7 GB) niż „mikro instancja” (0,64 GB), kosztuje dodatkowe pieniądze

b) dodanie partycja swap - dodać dodatkowy dysk EBS, mkswap /dev/sdx, swapon /dev/sdx, kosztów składowania i opłat EBS IO

c) dodanie pliku wymiany - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, koszty opłat IO i ilość wolnego miejsca na głównym EBS

C) powinno wystarczyć, ale należy pamiętać, że mikro instancja nie powinna uruchamiać długotrwałych zadań intensywnie obciążających procesor ze względu na ograniczenia procesora (dozwolone są tylko krótkie serie).

— yaplik
źródło
3

Miałem ten sam problem. Moje procesy zostały zabite.

Dowiedziałem się, że używany przeze mnie Ubuntu AMI nie ma skonfigurowanej przestrzeni wymiany. Gdy pamięć jest pełna i nie ma dostępnej przestrzeni wymiany, jądro nieprzewidywalnie rozpocznie procesy zabijania, aby się zabezpieczyć. Zamień przestrzeń zapobiega temu. (Ten problem jest szczególnie istotny w przypadku instancji Micro ze względu na małe 613 MB pamięci.)

Aby sprawdzić, czy masz skonfigurowaną przestrzeń wymiany, wpisz: swapon -s

Skonfiguruj przestrzeń wymiany: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

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

— Pyszne
źródło
Pracował dla mnie! Mój dmesg zawierał tylko wiele „select proccess_name to kill” jeden po drugim i nie miałem / var / log / messages ani żadnych przydatnych logów, ale uruchomienie „free -h” pokazało, że prawie nie ma już pamięci. Wielkie dzięki!
— divieira
1

Dziennik informuje, że kończy się pamięć wymiany / pamięci podręcznej.

    14 maja 20:29:15 ip-10-112-33-63 jądro: [11144050.272240] 0 stron w buforze wymiany
    14 maja 20:29:15 ip-10-112-33-63 jądro: [11144050.272242] Zamień statystyki pamięci podręcznej: dodaj 0, usuń 0, znajdź 0/0
    14 maja 20:29:15 ip-10-112-33-63 jądro: [11144050.272243] Swap za darmo = 0kB
    14 maja 20:29:15 ip-10-112-33-63 jądro: [11144050.272244] Całkowita zamiana = 0kB

Czy możesz podzielić zadanie / proces, który uruchamiasz partiami? Być może możesz spróbować uruchomić go w izolacji po zatrzymaniu innych procesów?

— Mechanik oprogramowania
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.