Co zabiło mój proces i dlaczego?

Try:

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

Gdzie -B100 oznacza liczbę linii przed zabiciem.

Omit - T na Mac OS.

To wygląda jak dobry artykuł na ten temat: Oswajanie zabójcy OOM .

Najważniejsze jest to, że Linux nadmiaruje pamięć. Kiedy proces prosi o więcej miejsca, Linux da mu tę przestrzeń, nawet jeśli jest ona żądana przez inny proces, przy założeniu, że nikt nie używa całej pamięci, o którą prosi. Proces uzyska wyłączne użycie pamięci, którą przydzielił, gdy faktycznie z niej korzysta, a nie gdy o nią poprosi. Dzięki temu przydział jest szybki i może pozwól ci "oszukiwać" i przeznaczyć więcej pamięci niż naprawdę masz. Jednak gdy procesy zaczną używać tej pamięci, Linux może zdać sobie sprawę, że był zbyt hojny w przydzielaniu pamięci, której nie ma, i będzie musiał zabić proces, aby uwolnić część. Proces, który ma zostać zabity, opiera się na wyniku uwzględniającym runtime( długotrwałe procesy są bezpieczniejsze), zużycie pamięci (chciwe procesy są mniej bezpieczne) i kilka innych czynników, w tym wartość, którą można dostosować, aby proces był mniej bezpieczny prawdopodobnie zostanie zabity. Wszystko to jest opisane w artykule w dużo bardziej szczegółowo.

Edit: A oto kolejny artykuł , który dość dobrze wyjaśnia, w jaki sposób Proces jest wybierany(opatrzony kilkoma przykładami kodu jądra). Wspaniałą rzeczą w tym jest to, że zawiera komentarz do rozumowania za różnymi badness() zasadami.

Pozwól, że najpierw wyjaśnię kiedy i dlaczego oomkiller został wywołany?

Powiedzmy, że masz 512 RAM + 1GB pamięci wymiany. Teoretycznie procesor ma dostęp do 1,5 GB pamięci wirtualnej.

Teraz, Od pewnego czasu wszystko działa dobrze w 1.5 GB całkowitej pamięci. Ale nagle (lub stopniowo) Twój system zaczął zużywać coraz więcej pamięci i osiągnął w punkcie około 95% całkowitej używanej pamięci.

Teraz powiedzmy, że każdy proces zażądał dużej ilości pamięci z kernel. Sprawdź dostępną pamięć jądra i znajdź, że nie ma możliwości, aby przydzielić procesowi więcej pamięci. Więc będzie próbował uwolnić niektóre wywołania pamięci / wywołania OOMKiller ( http://linux-mm.org/OOM).

OOMKiller ma swój własny algorytm do oceny rang dla każdego procesu. Zazwyczaj który proces zużywa więcej pamięci staje się ofiarą do zabicia.

Gdzie mogę znaleźć logi OOMKiller?

Zazwyczaj w katalogu / var / log. Albo / var / log / kern.log lub / var / log / dmesg

Niektóre typowe rozwiązania:

1. Zwiększ pamięć (nie zamieniaj)
2. Znajdź wycieki pamięci w swoim programie i napraw je
Pamięć JVM może być wykorzystywana przez dowolny proces (na przykład pamięć JVM może być ograniczona za pomocą JAVA_OPTS).]}
3. Zobacz logi i google:)

To jest Linux out of memory manager (OOM) . Twój proces został wybrany ze względu na "badness " - połączenie niedawności, rozmiaru rezydenta (pamięci w użyciu, a nie tylko przydzielonej) i innych czynników.

sudo journalctl -xb

Zobaczysz wiadomość w stylu:

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

Jak stwierdzili dwc i Adam Jaśkiewicz, winowajcą jest prawdopodobnie Zabójca OOM. Kolejne pytanie brzmi jednak: jak temu zapobiec?

Istnieje kilka sposobów:

1. daj systemowi więcej pamięci RAM, jeśli możesz (łatwo, jeśli jest to VM)
Upewnij się, że zabójca OOM wybiera inny proces.
2. Disable the Oom Killer
3. Wybierz dystrybucję Linuksa, która będzie dostarczana z wyłączonym zabójcą OOM.

Uznałem (2) za szczególnie łatwe do wdrożenia, dzięki Ten artykuł .

Narzędzie takie jak systemtap (lub tracer) może monitorować logikę transmisji sygnału jądra i raportować. np. 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

Blok filtrowania if w tym skrypcie może być dostosowany do smaku lub wyeliminowany do śledzenia ruchu sygnałowego w całym systemie. Przyczyny mogą być dalej izolowane przez zbieranie ścieżek wstecznych(dodaj print_backtrace() i / lub print_ubacktrace() do sondy, odpowiednio dla jądra i przestrzeni użytkownika).

Moduł Pam do ograniczania zasobów spowodował dokładnie takie wyniki, jakie opisałeś: mój proces zmarł w tajemniczy sposób z tekstem zabitym w oknie konsoli. Brak wyjścia dziennika, ani w syslog, ani w kern.log . Program top pomógł mi odkryć, że dokładnie po jednej minucie użycia procesora mój proces zostaje zabity.

W środowisku LSF (interaktywnym lub innym), jeśli aplikacja przekroczy określony próg wykorzystania pamięci przez administratorów w kolejce lub żądanie zasobów w kolejce, procesy zostaną zabite, aby inni użytkownicy nie padli ofiarą potencjalnej ucieczki. Nie zawsze wysyła wiadomość e-mail, gdy to robi, w zależności od tego, jak jest skonfigurowany.

Jednym z rozwiązań w tym przypadku jest znalezienie kolejki z większymi zasobami lub zdefiniowanie większych wymagań zasobów w Uległość.

Możesz również przejrzeć man ulimit

Chociaż nie pamiętam ulimit w wyniku Killed minęło trochę czasu, odkąd tego potrzebowałem.

Mieliśmy powtarzające się problemy pod Linuksem na stronie klienta (Red Hat, myślę), z OOMKiller (out-of-memory killer) zabijając zarówno naszą podstawową aplikację (tj. powód istnienia serwera), jak i jej procesy baz danych.

W każdym przypadku OOMKiller po prostu zdecydował, że procesy zużywają dużo zasobów... maszyna nie miała nawet zawieść z powodu braku środków. Ani aplikacja, ani jej baza danych nie mają problemów z wyciekami pamięci (lub jakimkolwiek innym zasobem przeciek).

Nie jestem ekspertem od Linuksa, ale raczej uznałem, że jego algorytm decydowania, kiedy coś zabić, a co zabić, jest złożony. Ponadto powiedziano mi (nie mogę mówić o dokładności tego), że OOMKiller jest pieczony w jądrze i nie można go po prostu nie uruchomić.

Użytkownik ma możliwość zabijania własnych programów, używając kill lub Control + C, ale odnoszę wrażenie, że tak się nie stało i że użytkownik narzekał na Ciebie.

Root ma oczywiście możliwość zabijania programów, ale jeśli ktoś ma roota na twoim komputerze i zabija rzeczy, masz większe problemy.

Jeśli nie jesteś sysadminem, sysadmin może skonfigurować limity użycia procesora, pamięci RAM, dysku ort i automatycznie zabija procesy, które je przekraczają.

Inne niż te zgaduje, nie jestem pewien bez więcej informacji o programie.

Ostatnio napotkałem ten problem. W końcu odkryłem, że moje procesy zostały zabite zaraz po tym, jak aktualizacja openSUSE zypper została wywołana automatycznie. Aby wyłączyć aktualizację zypper rozwiązał mój problem.