Большинство длительных команд мгновенно убиваются на 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 для различных типов использования памяти или процессора, которые вы можете проверить, используя ulimit -H -a
  • Если в системе недостаточно виртуальной памяти, процессы могут быть убиты ядром oom-killer для освобождения памяти (в вашем случае, вероятно, дело не в этом)
  • Если в системе установлены SELinux и / или PaX / grsecurity, процесс может быть убит, если он попытается сделать что-то, что не разрешено политикой безопасности, или если он попытается выполнить самоизмененный код.

Журналы или dmesg должны сказать вам, почему процесс был убит.

вереск
источник
Спасибо за Ваш ответ! Только что проверил файлы журналов, которые вы упомянули, но я не могу найти много полезных данных. Проверьте обновление моего ответа, чтобы увидеть проблеск.
Дэн Левенхерц
3
Да, ты становишься немного убийцей; это означает, что у вас не хватает памяти. Попробуйте добавить некоторое пространство подкачки в ваш экземпляр (даже несколько сотен мегабайт подкачки могут помочь в ситуации нехватки памяти).
Хит
Для других, кто задавался вопросом, как добавить подкачку в экземпляр EC2, мне помог этот ответ (после SSHing в экземпляр): stackoverflow.com/a/17173973/4900327
Абхишек Дивекар
10

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

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

rthomson
источник
У убийцы OOM есть определенное предпочтение долгосрочным, малоактивным процессам. Убить sshd на рабочем сервере очень сложно.
mfarver
Sshd корректирует свой собственный счет / proc / pid / oom_adj, чтобы он не мог быть убит oom killer (до того, как он убьет все остальное).
яплик
@yaplik Похоже, это больше не относится к последним дистрибутивам. Поскольку дочерние процессы наследуют значение oom_adj, злонамеренный пользователь может вызвать DoS, потребляя всю память без того, чтобы его / ее процессы были убиты убийцей OOM.
ikso
4

Как уже объяснили другие, у вас не хватает памяти, поэтому убийца из памяти срабатывает и убивает какой-то процесс.

Вы можете исправить это, выполнив одно из следующих действий:

а) модернизировать свою машину 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) должно быть достаточно, но имейте в виду, что микроэкземпляр не должен запускать длительные задачи с интенсивным использованием процессора из-за ограничений процессора (допускаются только короткие пакеты).

yaplik
источник
3

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

Я обнаружил, что в Ubuntu AMI, который я использовал, не было настроено пространство подкачки. Когда память заполнена и свободного пространства подкачки нет, ядро ​​непредсказуемо начнет убивать процессы, чтобы защитить себя. Поменять местами пространство не позволяет. (Эта проблема особенно актуальна для экземпляра Micro из-за небольших 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 содержал только одно «выбрать имя_процесса для уничтожения» одно за другим, и у меня не было / var / log / messages или каких-либо полезных журналов, но запуск «free -h» показал, что памяти почти не осталось. Большое спасибо!
Divieira
1

В журнале говорится, что у вас заканчивается память подкачки / кеша.

    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] Free swap = 0kB
    14 мая 20:29:15 ip-10-112-33-63 ядро: [11144050.272244] Общий обмен = 0 КБ

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

Программный Механик
источник