Більшість давно запущених команд миттєво вбиваються на Amazon EC2 (Ubuntu 10.04)

26

Під час виконання будь-якої тривалої команди в терміналі програма миттєво гине і термінал виводить текст Killed.

Якісь покажчики? Можливо, є файл журналу з даними, що пояснюють, чому команди вбиваються?

Оновлення

Ось фрагмент, dmesgякий, сподіваємось, повинен висвітлити те, що викликає проблему. Ще одна примітка, яка може бути корисною, - це те, що це екземпляр 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

— Ден Лоєнгерц
джерело

Дуже корисно, тільки що був той самий випуск

— Cookie

36

Ви повинні мати можливість дізнатися, що вбило ваш процес, поглянувши на результат dmesgкоманди; або в логах /var/log/kern.log, /var/log/messagesабо /var/log/syslog.

Існує низка речей, які можуть призвести до того, що процес може бути вбитий на шум:

Якщо він перевищує важке полегшення для різних типів використання пам'яті або процесора, які ви можете перевірити, використовуючи ulimit -H -a
Якщо в системі недостатньо віртуальної пам’яті, процеси можуть загинути ядрами-вбивцями, щоб звільнити пам’ять (У вашому випадку, мабуть, це не так)
Якщо в системі встановлено SELinux та / або PaX / grsecurity, процес може загинути, якщо він спробує зробити те, що заборонено політикою безпеки, або якщо він намагається виконати самомодифікований код.

Журнали або dmesg повинні повідомити, чому процес був убитий.

— Хіт
джерело

Дякую за вашу відповідь! Щойно перевірив згадані вами журнали, але я не можу знайти багато корисних даних. Перегляньте оновлення моєї відповіді, щоб побачити огляд.

— Dan Loewenherz

3

Так, вас покусає вбивця; а це означає, що у вас не вистачає пам'яті. Спробуйте додати у свій примірник трохи місця (навіть лише кілька сотень мегів підкачки можуть багато допомогти у ситуації з низькою пам'яттю).

— Хіт

Для тих , хто задавався питанням, як додати своп до примірника EC2, ця відповідь допоміг мені (після SSHing в екземпляр): stackoverflow.com/a/17173973/4900327

— Абхішек Divekar

10

Журнали, які ви опублікували як в оновленнях, вказують, що у вашої системи не вистачає пам’яті, і вбивця OOM вимагає знищення процесів, щоб зберегти вільну пам’ять, коли «все інше виходить з ладу». Алгоритм вибору вбивці OOM може бути сприятливо орієнтований на ваші "тривалі" процеси. Ознайомтесь із пов’язаною сторінкою для опису алгоритму вибору.

Очевидним рішенням є більше пам’яті, але у вас може не вистачити пам’яті через витік пам’яті десь і додавання більше пам’яті, ймовірно, лише затримає виклик вбивці OOM, якщо це так. Перевірте таблицю процесів на наявність процесів, використовуючи найбільшу пам’ять за допомогою улюбленого інструменту (верх, ps тощо) та перейдіть звідти.

— ромсон
джерело

Убивця OOM має певну перевагу перед тривалими процесами з низькою активністю. Його вбивство sshd на виробничому сервері робить налагодження складним.

— mfarver

Sshd коригує свій власний / proc / pid / oom_adj рахунок, щоб його не вбили убивці oom (перш ніж він вбиває все інше).

— яплик

@yaplik Це, здається, більше не застосовується до останніх дистрибутивів. Оскільки дочірні процеси успадковують значення oom_adj, зловмисний користувач може викликати DoS, витрачаючи всю пам'ять, не вбиваючи його вбивцю OOM.

— ikso

4

Як уже пояснювали інші, у вас не вистачає пам'яті, тому вбивця пам’яті спрацьовує і вбиває певний процес.

Ви можете це виправити:

a) оновіть свою машину ec2 до більш потужної, "маленький екземпляр" має в 2,5 рази більше пам'яті (1,7 ГБ), ніж "мікроаппарат" (0,64 ГБ), коштує додаткові гроші

б) додавання розділу підкачки - додати додатковий диск EBS, mkswap /dev/sdx, swapon /dev/sdx, вартість зберігання EBS і збори введення - виведення

з) додавання файлу підкачки - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, варто плату введення - виведення і вільного простору на кореневої системі EBS

C) має бути достатнім, але майте на увазі, що мікро екземпляр не повинен виконувати тривалі завдання, що займаються процесором через обмеження процесора (допускаються лише короткі розриви).

— яплик
джерело

3

У мене була така ж проблема. Мої процеси вбивалися.

Я дізнався, що Ubuntu AMI, яким я користувався, не створив місця для заміни. Коли пам'ять заповнена і немає місця для обміну, ядро непередбачувано почне вбивати процеси, щоб захистити себе. Простір заміни перешкоджає цьому. (Ця проблема особливо актуальна для мікроприкладу через невеликі 613 Мб пам'яті.)

Щоб перевірити, чи є у вас тип налаштування місця для заміни: swapon -s

Налаштування простору підкачки: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

Інші ресурси: http://wiki.sysconfig.org.uk/display/howto/Build+your+own+Core+CentOS+5.x+AMI+for+Amazon+EC2

— Смачний
джерело

Працювали для мене! Мій dmesg містив лише багато "вибору proccess_name для вбивства" один за одним, і у мене не було / var / log / повідомлень чи будь-яких корисних журналів, але запуск "free -h" показав, що пам'яті майже не залишилось. Велике дякую!

— дівейра

1

Журнал говорить, що у вас закінчено пам'ять swap / кеш.

    14 травня 20:29:15 ip-10-112-33-63 ядро: [11144050.272240] 0 сторінок у кеш-пам'яті
    14 травня 20:29:15 ip-10-112-33-63 ядро: [11144050.272242] Статистика кешу поміняти: додати 0, видалити 0, знайти 0/0
    14 травня 20:29:15 ip-10-112-33-63 ядро: [11144050.272243] Безкоштовний своп = 0 кБ
    14 травня 20:29:15 ip-10-112-33-63 ядро: [11144050.272244] Загальний своп = 0 кБ

Чи можете ви розділити роботу / процес, який ви виконуєте, за партіями? Можливо, ви можете спробувати запустити його ізольовано після зупинки інших процесів?

— Механік програмного забезпечення
джерело