Cosa ha ucciso il mio processo e perché?
La mia applicazione funziona come un processo in background su Linux. È attualmente avviato dalla riga di comando in una finestra di Terminale.
Recentemente un utente stava eseguendo l'applicazione per un po 'ed è morto misteriosamente. Il testo:
Ucciso
era sul terminale. Questo è successo due volte. Ho chiesto se qualcuno in un terminale diverso ha usato il comando kill per uccidere il processo? No.
In quali condizioni Linux deciderebbe di uccidere il mio processo? Credo che la Shell sia stata "uccisa" perché il processo è morto dopo aver ricevuto il segnale di uccisione (9). Se Linux ha inviato il segnale kill dovrebbe esserci un messaggio in un log di sistema da qualche parte che spiega perché è stato ucciso?
Se l'utente o sysadmin non ha ucciso il programma che potrebbe avere il kernel. Il kernel ucciderebbe solo un processo in circostanze eccezionali, come l'esaurimento estremo delle risorse (think mem + swap esaurimento).
Provare:
dmesg -T| grep -E -i -B100 'killed process'
Dove -B100 indica il numero di righe prima che avvenisse l'uccisione.
Ometti -T su Mac OS.
Questo sembra un buon articolo sull'argomento: Domare il killer di OOM .
The Gist è la memoria di Linux overcommits. Quando un processo richiede più spazio, Linux gli darà quello spazio, anche se è rivendicato da un altro processo, partendo dal presupposto che nessuno usa effettivamente tutta la memoria che chiedono. Il processo otterrà l'uso esclusivo della memoria che ha allocato quando effettivamente lo usa, non quando lo richiede. Questo rende l'allocazione rapida e potrebbe consentire di "imbrogliare" e allocare più memoria di quanta ne hai davvero. Tuttavia, una volta che i processi iniziano a usare questa memoria, Linux potrebbe rendersi conto che è stato troppo generoso nell'allocare la memoria che non ha, e dovrà uccidere un processo per liberarlo. Il processo da uccidere si basa su un punteggio che tiene conto del runtime (i processi di lunga durata sono più sicuri), l'utilizzo della memoria (i processi avidi sono meno sicuri) e alcuni altri fattori, incluso un valore che è possibile regolare per rendere un processo meno probabilmente da uccidere. È tutto descritto nell'articolo in molti più dettagli.
Modifica: E qui è un altro articolo che spiega piuttosto bene come viene scelto un processo (annotato con alcuni esempi di codice del kernel). Il bello di questo è che include alcuni commenti sul reasoning dietro le varie regole badness().
Vorrei prima spiegare quando e perché OOMKiller viene richiamato?
Supponiamo tu abbia 512 RAM + 1GB di memoria di scambio. Quindi, in teoria, la tua CPU ha accesso a un totale di 1,5 GB di memoria virtuale.
Ora, per un po 'di tempo tutto sta funzionando bene con 1,5 GB di memoria totale. Ma all'improvviso (o gradualmente) il tuo sistema ha iniziato a consumare sempre più memoria e ha raggiunto a circa il 95% della memoria totale utilizzata.
Ora diciamo che qualsiasi processo ha richiesto un grande chunck di memoria dal kernel. Il kernel controlla la memoria disponibile e trova che non è in alcun modo in grado di allocare più memoria al processo. Quindi proverà a liberare memoria richiamando/invocando OOMKiller ( http://linux-mm.org/OOM ).
OOMKiller ha il proprio algoritmo per ottenere il punteggio per ogni processo. In genere, quale processo utilizza più memoria diventa la vittima da uccidere.
Dove posso trovare i log di OOMKiller?
Tipicamente nella directory/var/log. O /var/log/kern.log o/var/log/dmesg
Spero che questo ti possa aiutare.
Alcune soluzioni tipiche:
- Aumentare la memoria (non scambiare)
- Trova le perdite di memoria nel tuo programma e risolvile
- Limitare la memoria che qualsiasi processo può consumare (ad esempio la memoria JVM può essere limitata usando Java_OPTS)
- Guarda i log e google :)
Questo è Linux out of memory manager (OOM) . Il tuo processo è stato selezionato a causa di ' cattiva ' - una combinazione di recentizza, dimensione residente (memoria in uso, piuttosto che appena assegnata) e altri fattori.
Sudo journalctl -xb
Vedrai un messaggio come:
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
Come hanno dichiarato dwc e Adam Jaskiewicz, il colpevole è probabilmente OOM Killer. Tuttavia, la prossima domanda che segue è: Come posso evitare questo?
Ci sono diversi modi:
- Dai al tuo sistema più RAM se puoi (facile se è una VM)
- Assicurati che l'assassino di OOM scelga un processo diverso.
- Disabilita OOM Killer
- Scegli una distribuzione Linux fornita con OOM Killer disabilitata.
Ho trovato (2) per essere particolarmente facile da implementare, grazie a questo articolo .
Il modulo PAM per limitare le risorse ha causato esattamente i risultati che hai descritto: Il mio processo è morto misteriosamente con il testo Killed nella finestra della console. Nessun output di registro, né in syslog né in kern.log. Il programma top mi ha aiutato a scoprire che esattamente dopo un minuto di utilizzo della CPU il mio processo viene ucciso.
Uno strumento come systemtap (o un tracciante) può monitorare la logica di trasmissione del segnale del kernel e generare report. ad esempio, 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
Il blocco if block in quello script può essere regolato a piacere o eliminato per tracciare il traffico di segnale a livello di sistema. Le cause possono essere ulteriormente isolate raccogliendo backtrace (aggiungere un print_backtrace() e/o print_ubacktrace() al probe, rispettivamente per kernel e userspace-).
In un ambiente lsf (interattivo o di altro tipo) se l'applicazione supera l'utilizzo della memoria oltre una certa soglia preimpostata dagli amministratori in coda o dalla richiesta di risorse in invio alla coda, i processi verranno uccisi in modo che altri utenti non cadano vittima di un potenziale scappa. Non sempre invia un'email quando lo fa, a seconda di come è stata impostata.
Una soluzione in questo caso consiste nel trovare una coda con risorse più grandi o definire requisiti di risorse più grandi nell'invio.
Potresti anche voler recensire man ulimit
Anche se non ricordo ulimit risultante in Killed, è passato un po 'di tempo da quando ne avevo bisogno.
Abbiamo avuto problemi ricorrenti sotto Linux in un sito cliente (Red Hat, credo), con OOMKiller (killer esaurito) che uccide sia la nostra principale applicazione (vale a dire il motivo per cui il server esiste) sia i suoi processi di base dati.
In ogni caso, OOMKiller ha semplicemente deciso che i processi utilizzavano molte risorse ... la macchina non stava nemmeno per fallire per mancanza di risorse. Né l'applicazione né il suo database hanno problemi con perdite di memoria (o altre perdite di risorse).
Non sono un esperto di Linux, ma piuttosto ho raccolto il suo algoritmo per decidere quando uccidere qualcosa e cosa uccidere è complesso. Inoltre, mi è stato detto (non posso parlare della precisione di questo) che OOMKiller è cotto nel kernel e non si può semplicemente non eseguirlo.
Risolto il problema con aumentando la dimensione dello scambio :
https://askubuntu.com/questions/1075505/how-do-i-rease-swapfile-in-ubuntu-18-04
Ho riscontrato questo problema ultimamente. Alla fine, ho scoperto che i miei processi sono stati uccisi subito dopo l'apertura di Opensuse zypper. Per disabilitare l'aggiornamento di zypper ho risolto il mio problema.
L'utente ha la possibilità di uccidere i propri programmi, usando kill o Control + C, ma ho l'impressione che non sia quello che è successo e che l'utente si sia lamentato con te.
root ha la capacità di uccidere i programmi, ovviamente, ma se qualcuno ha root sulla tua macchina e sta uccidendo roba hai problemi più grandi.
Se non si è l'amministratore di sistema, è possibile che il sysadmin abbia impostato quote su CPU, RAM, utilizzo del disco o processi di auto-uccisione che li superano.
A parte queste ipotesi, non sono sicuro senza ulteriori informazioni sul programma.
Nel mio caso questo stava accadendo con un addetto alla coda di Laravel. I log di sistema non menzionavano alcuna uccisione, quindi ho guardato oltre e si è scoperto che il lavoratore stava praticamente uccidendo se stesso a causa di un lavoro che superava il limite di memoria (che è impostato su 128 M per impostazione predefinita).
L'esecuzione del queue worker con --timeout=600 e --memory=1024 ha risolto il problema per me.