Что убило мой процесс и почему? - PullRequest
539 голосов
/ 07 апреля 2009

Мое приложение работает в Linux как фоновый процесс. В настоящее время он запускается из командной строки в окне терминала.

Недавно пользователь некоторое время выполнял приложение, и оно загадочным образом умерло. Текст:

Убит

был на терминале. Это случилось два раза. Я спросил, использует ли кто-то в другом Терминале команду kill для уничтожения процесса? Нет.

При каких условиях Linux решит убить мой процесс? Я полагаю, что оболочка показала «kill», потому что процесс умер после получения сигнала kill (9). Если Linux отправил сигнал уничтожения, должно ли быть какое-либо сообщение в системном журнале, объясняющее, почему оно было убито?

Ответы [ 14 ]

355 голосов
/ 07 апреля 2009

Если пользователь или системный администратор не убили программу, возможно, ядро. Ядро будет уничтожать процесс только при исключительных обстоятельствах, таких как чрезмерное истощение ресурсов (например, mem + swap исчерпание).

217 голосов
/ 19 декабря 2013

Попробуйте:

dmesg -T| grep -E -i -B100 'killed process'

Где -B100 обозначает количество строк до того, как произошло уничтожение.

Пропустить -T в Mac OS.

163 голосов
/ 07 апреля 2009

Это похоже на хорошую статью на эту тему: Укрощение убийцы OOM .

Суть в том, что Linux перегружает память. Когда процесс запрашивает больше места, Linux предоставит ему это пространство, даже если это запрашивается другим процессом, исходя из предположения, что никто фактически не использует всю запрашиваемую им память. Процесс получит исключительное использование памяти, которую он выделил, когда он фактически использует ее, а не когда он запрашивает ее. Это делает распределение быстрым и может позволить вам «обмануть» и выделить больше памяти, чем у вас есть на самом деле. Однако, как только процессы начнут использовать эту память, Linux может понять, что она слишком щедра в распределении памяти, которой у нее нет, и ей придется убить процесс, чтобы освободить его. Уничтожаемый процесс основан на оценке с учетом времени выполнения (длительные процессы безопаснее), использования памяти (жадные процессы менее безопасны) и нескольких других факторов, в том числе значения, которое можно настроить, чтобы сделать процесс менее может быть убит. Все это описано в статье более подробно.

Редактировать: А вот другая статья , которая довольно хорошо объясняет, как выбирается процесс (аннотировано некоторыми примерами кода ядра). Самое замечательное в этом то, что он содержит некоторые комментарии к рассуждению , стоящему за различными badness() правилами.

43 голосов
/ 05 апреля 2016

Позвольте мне сначала объяснить, когда и почему вызывается OOMKiller?

Скажем, у вас есть 512 RAM + 1 ГБ подкачки памяти. Таким образом, теоретически ваш ЦП имеет доступ к 1,5 ГБ виртуальной памяти.

Теперь в течение некоторого времени все работает нормально в пределах 1,5 ГБ общей памяти. Но внезапно (или постепенно) ваша система начала потреблять все больше и больше памяти, и она достигла примерно 95% от общего объема используемой памяти.

Теперь скажите, что любой процесс запросил у ядра большой кусок памяти. Ядро проверит доступную память и обнаружит, что нет способа выделить вашему процессу больше памяти. Поэтому он попытается освободить память, вызывающую / вызывающую OOMKiller (http://linux -mm.org / OOM ).

OOMKiller имеет свой собственный алгоритм для оценки ранга для каждого процесса. Как правило, какой процесс использует больше памяти, становится жертвой, которую нужно убить.

Где я могу найти логи OOMKiller?

Обычно в каталоге / var / log. Либо /var/log/kern.log или / var / log / dmesg

Надеюсь, это поможет вам.

Некоторые типичные решения:

  1. Увеличение памяти (не подкачка)
  2. Найдите утечки памяти в вашей программе и исправьте их
  3. Ограничить память, которую может использовать любой процесс (например, память JVM может быть ограничена с помощью JAVA_OPTS)
  4. см логи и гугл:)
15 голосов
/ 20 июля 2015

Это менеджер Linux out of memory (OOM) . Ваш процесс был выбран из-за ' badness ' - сочетания недавности, резидентного размера (используемой памяти, а не только выделенной) и других факторов.

sudo journalctl -xb

Вы увидите сообщение типа:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB
11 голосов
/ 28 января 2014

Как заявили dwc и Адам Яскевич, виновник, скорее всего, убийца ООМ. Тем не менее, следующий вопрос, который следует: как я могу предотвратить это?

Есть несколько способов:

  1. Дайте вашей системе больше оперативной памяти, если можете (легко, если это виртуальная машина)
  2. Убедитесь, что убийца OOM выбирает другой процесс.
  3. Отключить OOM Killer
  4. Выберите дистрибутив Linux, поставляемый с отключенным OOM Killer.

Я нашел (2) особенно легко реализовать благодаря этой статье .

9 голосов
/ 26 апреля 2012

Модуль PAM для ограничения ресурсов вызвал именно те результаты, которые вы описали: мой процесс загадочным образом умер с текстом Killed в окне консоли. Нет вывода журнала, ни в syslog , ни в kern.log . Программа top помогла мне обнаружить, что ровно после одной минуты использования процессора мой процесс прерывается.

7 голосов
/ 25 февраля 2015

Такой инструмент, как systemtap (или трассировщик), может контролировать логику передачи сигналов ядра и создавать отчеты. например, https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

Блок фильтрации if в этом скрипте может быть настроен по вкусу или исключен для отслеживания общесистемного сигнального трафика. Причины могут быть дополнительно изолированы путем сбора обратных следов (добавьте print_backtrace() и / или print_ubacktrace() к зонду для ядра и пользовательского пространства соответственно).

4 голосов
/ 03 марта 2012

В среде lsf (интерактивной или другой), если приложение превышает использование памяти сверх некоторого предварительно установленного порога администраторами в очереди или запросом ресурсов при отправке в очередь, процессы будут убиты, чтобы другие пользователи не стали жертвами к потенциальному бегству. При этом он не всегда отправляет электронное письмо, в зависимости от того, как он настроен.

Одним из решений в этом случае является поиск очереди с большими ресурсами или определение более высоких требований к ресурсам в представлении.

Вы также можете рассмотреть man ulimit

Хотя я не помню ulimit, в результате чего Killed прошло некоторое время, так как я нуждался в этом.

2 голосов
/ 07 апреля 2009

У нас периодически возникали проблемы под Linux на сайте заказчика (я думаю, Red Hat), когда OOMKiller (убийца нехватки памяти) убивал как наше основное приложение (то есть причину существования сервера), так и процессы базы данных ,

В каждом случае OOMKiller просто решал, что процессы используют много ресурсов ... машина даже не собирается выходить из строя из-за нехватки ресурсов. Ни у приложения, ни у его базы данных нет проблем с утечками памяти (или любой другой утечкой ресурсов).

Я не эксперт по Linux, но скорее собрал его алгоритм для определения, когда убивать что-то, а что убивать - сложно. Кроме того, мне сказали (я не могу говорить о точности этого), что OOMKiller запекается в ядре, и вы просто не можете его не запускать.

...