Sebagian besar perintah yang telah berjalan lama langsung terbunuh di Amazon EC2 (Ubuntu 10.04)


26

Saat menjalankan segala jenis perintah yang berjalan lama di terminal, program langsung mati dan terminal mengeluarkan teks Killed.

Ada petunjuk? Mungkin ada file log dengan data yang menjelaskan mengapa perintah itu dibunuh?

Memperbarui

Berikut ini cuplikan dari dmesgyang semoga dapat menerangi apa yang menyebabkan masalah ini. Catatan lain yang mungkin bermanfaat adalah ini adalah 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

Sangat membantu, baru saja mengalami masalah yang sama
Cookie

Jawaban:


36

Anda harus dapat mengetahui apa yang mematikan proses Anda dengan melihat output dari dmesgperintah; atau di logfiles /var/log/kern.log, /var/log/messagesatau /var/log/syslog.

Ada beberapa hal yang dapat menyebabkan proses dibunuh:

  • Jika melebihi hard ulimit untuk berbagai jenis penggunaan memori atau cpu yang dapat Anda periksa menggunakan ulimit -H -a
  • Jika sistem kehabisan memori virtual, proses dapat terbunuh oleh kernel oom-killer untuk membebaskan memori (Dalam kasus Anda, mungkin bukan ini)
  • Jika sistem memiliki SELinux, dan / atau PaX / grsecurity diinstal, suatu proses dapat terbunuh jika mencoba melakukan sesuatu yang tidak diizinkan oleh kebijakan keamanan, atau jika ia mencoba mengeksekusi kode yang dimodifikasi sendiri.

Log atau dmesg harus memberi tahu Anda mengapa prosesnya mati.


Terima kasih atas jawaban anda! Baru saja memeriksa file log yang Anda sebutkan, tetapi sepertinya saya tidak dapat menemukan banyak data yang berguna. Lihat pembaruan untuk jawaban saya untuk melihat sekilas.
Dan Loewenherz

3
Yap, Anda mendapatkan sedikit dari pembunuh-oom; yang berarti Anda kehabisan memori. Coba tambahkan beberapa ruang swap ke instance Anda (bahkan hanya beberapa ratus MB swap dapat banyak membantu dalam situasi memori rendah).
Heath

Bagi orang lain yang bertanya-tanya bagaimana cara menambahkan swap ke instance EC2, jawaban ini membantu saya (setelah SSHing menjadi contoh): stackoverflow.com/a/17173973/4900327
Abhishek Divekar

10

Log yang Anda posting sebagai pembaruan menunjukkan sistem Anda kehabisan memori dan pembunuh OOM sedang dipanggil untuk mematikan proses untuk menjaga memori bebas ketika "semuanya gagal". Algoritme pemilihan untuk pembunuh OOM mungkin menargetkan proses "lama berjalan" Anda. Lihat halaman tertaut untuk deskripsi algoritma pemilihan.

Solusi yang jelas adalah lebih banyak memori tetapi Anda mungkin kehabisan memori karena kebocoran memori di suatu tempat dan menambahkan lebih banyak memori kemungkinan hanya akan menunda pembunuh OOM dipanggil jika itu terjadi. Periksa tabel proses Anda untuk proses yang menggunakan memori terbanyak dengan alat favorit Anda (atas, ps, dll.) Dan pergi dari sana.


Pembunuh OOM memiliki preferensi yang pasti untuk proses yang berjalan lama dan aktivitas rendah. Setelah itu sshd membunuh pada server produksi membuat debugging rumit.
mfarver

Sshd menyesuaikan skor sendiri / proc / pid / oom_adj sehingga tidak dapat dibunuh oleh pembunuh oom (sebelum membunuh yang lainnya).
yaplik

@yaplik Ini sepertinya tidak berlaku lagi untuk distribusi terbaru. Saat proses anak mewarisi nilai oom_adj, pengguna yang jahat dapat menyebabkan DoS dengan mengonsumsi semua memori tanpa prosesnya terbunuh oleh pembunuh OOM.
ikso

4

Seperti yang sudah dijelaskan oleh orang lain, Anda kehabisan memori, jadi pembunuh memori dipicu dan membunuh beberapa proses.

Anda dapat memperbaiki ini dengan melakukan:

a) tingkatkan mesin EC2 Anda menjadi lebih kuat, 'contoh kecil' memiliki 2,5x lebih banyak memori (1,7GB) daripada 'contoh mikro' (0,64GB), membutuhkan biaya tambahan

b) menambahkan partisi swap - menambah tambahan EBS drive, mkswap /dev/sdx, swapon /dev/sdx, biaya penyimpanan EBS dan biaya IO

c) menambahkan file swap - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, biaya biaya IO dan ruang kosong pada akar EBS

C) harus memadai, tetapi perlu diingat bahwa instance mikro tidak seharusnya menjalankan tugas intensif cpu yang berjalan lama karena batas cpu (hanya ledakan singkat yang diizinkan).


3

Saya memiliki masalah yang sama. Proses saya terbunuh.

Saya menemukan bahwa AMI Ubuntu yang saya gunakan tidak memiliki ruang swap. Ketika memori penuh dan tidak ada ruang swap yang tersedia, kernel akan secara tak terduga mulai mematikan proses untuk melindungi dirinya sendiri. Swap space mencegah hal itu. (Masalah ini sangat relevan dengan instance Mikro karena kecilnya memori 613 MB.)

Untuk memeriksa apakah Anda memiliki pengaturan ruang swap: swapon -s

Siapkan ruang swap: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

Sumber-sumber lain: http://wiki.sysconfig.org.uk/display/howto/Build+your+own+Core+CentOS+5.x+AMI+for+Amazon+EC2


Bekerja untukku! Dmesg saya hanya berisi banyak "pilih proccess_name untuk dibunuh" satu demi satu dan saya tidak punya / var / log / pesan atau log yang berguna, tetapi menjalankan "free -h" menunjukkan hampir tidak ada memori yang tersisa. Terimakasih banyak!
divieira

1

Log mengatakan Anda kehabisan memori swap / cache.

    14 Mei 20:29:15 ip-10-112-33-63 kernel: [11144050.272240] 0 halaman dalam cache swap
    14 Mei 20:29:15 ip-10-112-33-63 kernel: [11144050.272242] Swap cache stats: tambah 0, hapus 0, temukan 0/0
    14 Mei 20:29:15 ip-10-112-33-63 kernel: [11144050.272243] Free swap = 0kB
    14 Mei 20:29:15 ip-10-112-33-63 kernel: [11144050.272244] Total swap = 0kB

Bisakah Anda membagi pekerjaan / proses yang Anda jalankan dalam batch? Mungkin Anda dapat mencoba menjalankannya secara terpisah setelah menghentikan proses lainnya?

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.