Uzun süredir çalışan çoğu komut Amazon EC2'de anında öldürüldü (Ubuntu 10.04)

26

Terminalde herhangi bir uzun süre çalışan komutu çalıştırırken, program anında ölür ve terminal metni çıkarır Killed.

Herhangi bir işaretçi var mı? Belki de komutların neden öldürüldüğünü açıklayan veriler içeren bir günlük dosyası vardır?

Güncelleştirme

İşte bu bir pasaj dmesgolduğunu umarım soruna neden olanı aydınlatmak gerekir. Yardımcı olabilecek bir başka not, bunun bir Amazon EC2 örneği olduğudur.

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
kaynak

Çok yardımcı oldu, sadece aynı sorunu vardı

— Cookie

36

dmesgKomutun çıktısına bakarak sürecinizi neyin öldürdüğünü öğrenebilmelisiniz ; veya logfiles de /var/log/kern.log, /var/log/messagesya da /var/log/syslog.

Bir sürecin genel olarak öldürülmesine neden olabilecek bazı şeyler vardır:

Kullanarak inceleyebileceğiniz çeşitli bellek veya cpu kullanım türleri için sabit ulimit değerini aşarsa ulimit -H -a
Sistem sanal hafızada düşükse, bellek boşalması için işlemler oom-katil tarafından öldürülebilir (Sizin durumunda, muhtemelen bu değil)
Sistemin içinde SELinux ve / veya PaX / grsecurity kurulu ise, güvenlik politikası tarafından izin verilmeyen bir şeyi yapmaya çalışırsa veya kendi kendini değiştiren kodu çalıştırmayı denerse bir işlem öldürülebilir.

Kayıtlar ya da dmesg size sürecin neden öldürüldüğünü söylemelidir.

— funda
kaynak

Cevabınız için teşekkürler! Bahsettiğiniz günlük dosyalarına baktım, ancak çok yararlı veriler bulamıyorum. Bir bakış görmek için cevabımın güncellemesine göz atın.

— Dan Loewenherz

3

Evet, katil tarafından ısırılıyorsunuz; Bu, hafızanız tükenmek demektir. Örneğinize bir miktar takas alanı eklemeyi deneyin (az miktarda bellek durumunda çok az yüzlerce takas bile yardımcı olabilir).

— Heath

Bir EC2 örneğine nasıl takas ekleyeceğini merak eden başkaları için, bu cevap bana yardımcı oldu (örneğe SSHing yaptıktan sonra): stackoverflow.com/a/17173973/4900327

— Abhishek Divekar

10

Güncelleme sırasında gönderdiğiniz günlükler, sisteminizin hafızasının tükendiğini ve OOM katilinin "hepsi başarısız" olduğunda boş belleği korumak amacıyla işlemleri sonlandırmak için çağrıldığını gösterir. OOM katili için seçim algoritması "uzun süren" işlemlerinizi olumlu şekilde hedefliyor olabilir. Seçim algoritmasının açıklaması için bağlantılı sayfaya bakınız.

Açıkça görünen çözüm daha fazla hafızadır, ancak bir yerde hafıza sızıntısı olması nedeniyle hafızanız tükenebilir ve daha fazla hafıza eklemek, muhtemelen durum söz konusu olduğunda OOM katilinin çağrılmasını geciktirir. Favori aracınızla (top, ps vb.) En fazla belleği kullanan işlemler için işlem tablonuzu kontrol edin ve oradan gidin.

— rthomson
kaynak

OOM katili, uzun süren, düşük aktivite süreçleri için kesin bir tercihe sahiptir. Bir üretim sunucusunda sshd'yi öldürmesi hata ayıklamayı zorlaştırır.

— mfarver

Sshd kendi / proc / pid / oom_adj puanını ayarlar, böylece oom katil tarafından öldürülemez (her şeyi öldürmeden önce).

— yaplik

@yaplik Bu, son dağıtımlara artık uygulanmamaktadır. Alt işlemler oom_adj'nin değerini devraldığından, kötü niyetli bir kullanıcı, işlemleri OOM katili tarafından öldürülmeden tüm belleği tüketerek DoS'a neden olabilir.

— ikso

4

Başkaları tarafından zaten açıklandığı gibi, hafızanız tükenir, bu nedenle hafıza dışı katil tetiklenir ve bazı işlemleri öldürür.

Bunu yaparak da düzeltebilirsiniz:

a) ec2 makinenizi daha güçlü bir sürücüye yükseltin, 'küçük örnek', 'mikro örnek' (0.64 GB) 'den 2.5 kat daha fazla belleğe (1.7 GB) sahiptir, ek ücrete tabidir

b) ekleyerek takas bölümü - Ek EBS sürücü ekleyebilir mkswap /dev/sdx, swapon /dev/sdxEBS depolama ve IO ücretleri maliyeti

c) takas dosyası ekleyerek - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, IO ücret ve kök EBS üzerinde boş alan maliyeti

C) yeterli olmalı, ancak mikro vakanın cpu limitleri nedeniyle uzun süren cpu yoğun görevler yürütmemesi gerektiğini (sadece kısa patlamalara izin verildiğini) unutmayın.

— yaplik
kaynak

3

Ben de aynı problemi yaşadım. İşlemlerim öldürülüyordu.

Kullandığım Ubuntu AMI’nin takas alanı bulunmadığını öğrendim. Hafıza dolu olduğunda ve takas alanı mevcut olmadığında, çekirdek kendini korumak için öngörülemeyen bir şekilde öldürme işlemlerine başlayacaktır. Yer değiştirmeyi önler. (Bu sorun özellikle küçük 613 MB bellekten dolayı Micro örneğiyle ilgilidir.)

Takas alanının ayarlı olup olmadığını kontrol etmek için: swapon -s

Takas alanını ayarlayın: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

Diğer kaynaklar: http://wiki.sysconfig.org.uk/display/howto/Build+your+own+Core+CentOS+5.x+AMI+ for+Amazon+EC2

— Lezzetli
kaynak

Benim için çalıştı! Dmesg'im birbiri ardına "öldürmek için" proccess_name seçti "içeriyordu ve / var / log / mesajlarım ya da herhangi bir yararlı logum yoktu, ancak" free -h "çalıştırmak neredeyse hiç hafıza kalmadı. Çok teşekkürler!

— divieira

1

Günlük, takas / önbellek tükenmekte olduğunu söylüyor.

    14 Mayıs 20:29:15 ip-10-112-33-63 çekirdeği: [11144050.272240] takas önbellekte 0 sayfa
    14 Mayıs 20:29:15 ip-10-112-33-63 çekirdek: [11144050.272242] Önbellek istatistiklerini değiştir: 0 ekle, 0 sil, 0/0 bul
    14 Mayıs 20:29:15 ip-10-112-33-63 çekirdeği: [11144050.272243] Serbest takas = 0kB
    14 Mayıs 20:29:15 ip-10-112-33-63 çekirdek: [11144050.272244] Toplam takas = 0kB

Yaptığınız işi / süreci gruplar halinde bölebilir misiniz? Belki de diğer işlemleri durdurduktan sonra tecritte çalıştırmayı deneyebilirsiniz?

— Yazılım Tamircisi
kaynak