Come convincere il killer OOM di Linux a non uccidere il mio processo?

28

Come posso convincere il killer OOM di Linux a non uccidere i miei processi quando la memoria fisica è bassa ma c'è molto spazio di scambio?

Ho disabilitato l'omicidio OOM e l'overcommit con sysctl vm.overcommit_memory = 2.

La VM ha 3 GB di swap senza frammentazione assolutamente gratuito e i processi che vengono uccisi da OOM hanno un utilizzo massimo di memoria inferiore a 200 MB.

So che lo scambio a lungo termine sarà orribile per le prestazioni, ma ora devo usare lo swap per fare test funzionali sotto valgrind dove i requisiti di memoria sono molto maggiori.

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

Questo è / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

linux swap oom

— Programmatore
fonte

8

È evidente palesemente dalla traccia della chiamata che il kernel non aveva memoria sufficiente. Per quanto riguarda il motivo per cui non è stato scambiato, ciò può avere molte cause diverse, tutte troppo lunghe per essere spiegate completamente in 500 caratteri. Ma il tuo sembra che non ci siano pagine recuperabili ( all_unreclaimableè sì). Queste sono pagine bloccate nella RAM, generalmente perché bloccate o utilizzate dal kernel. Nulla di ciò che era rimasto nella RAM era sostituibile al momento; tutto ciò che avrebbe potuto essere scambiato era già stato. Ancora una volta, la soluzione è più RAM.

— Michael Hampton

1

@MichaelHampton Il resto della memoria viene utilizzato da normali applicazioni. Perché il kernel non può spingerli a scambiarsi? Per favore, rispondi alla mia domanda "Se ciò che stai dicendo è vero, come potrebbe mai un processo spostarsi dopo che tutta la memoria fisica è stata usata?"

— Coder

1

@MichaelHampton Sto disabilitando il fork e ora fail2ban invoca il killer di Oom causando la morte dei miei processi. A che serve scambiare se il kernel non lo utilizzerà? Ancora più importante, come posso configurare il kernel in modo che smetta di rimanere senza memoria.

— Coder

4

@MatthewIfe: se conosci la risposta, per favore pubblicala qui. I siti Stack Exchange sono a vantaggio di tutti coloro che leggono, non solo dell'OP che ha posto la domanda.

— R ..

4

Lo scambio in una macchina virtuale non è considerato best practice. Alloca più memoria reale alla tua VM. Se non riesci ad aggiungere più memoria, portalo internamente all'hardware fisico invece di lasciarlo in un noleggio sottodimensionato.

— Criggie

36

Questo sembra essere un problema in combinazione di due fattori:

Utilizzando una macchina virtuale.
Un possibile bug del kernel.

Questa è in parte una delle righe che descrive il motivo per cui ciò accade:

7 mar 02:43:11 kernel myhost: memcheck-amd64- invocato oom-killer: gfp_mask = 0x24002c2, ordine = 0, oom_score_adj = 0

L'altra linea è questa:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| La prima riga è la maschera GFP assegnata per l'allocazione. Descrive sostanzialmente ciò che il kernel può / non può fare per soddisfare questa richiesta. La maschera indica un gruppo di bandiere standard. L'ultimo bit, '2' indica tuttavia che l'allocazione di memoria dovrebbe provenire dalla HighMemzona.

Se osservi attentamente l'output OOM, vedrai che nessuna HighMem/Normalzona esiste realmente.

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem(generalmente chiamato anche Normalx86_64) tende a mappare la memoria per zone al di fuori degli intervalli standard di 896 MiB direttamente accessibili al kernel su sistemi a 32 bit. Su x86_64 HighMem/Normalsembra coprire tutte le pagine di dimensioni superiori a 3GiB.

DMA32contiene una zona utilizzata per la memoria che sarebbe accessibile su dispositivi DMA a 32 bit, ovvero è possibile indirizzarli con puntatori a 4 byte. Credo che DMAsia per i dispositivi DMA a 16 bit.

In generale, Normalnon esisterebbero sistemi a memoria insufficiente , dato che DMA32copre già tutti gli indirizzi virtuali disponibili.

Il motivo per cui OOM uccide è perché esiste un'allocazione di memoria per una HighMemzona con 0 pagine disponibili. Dato che il gestore di memoria esaurita non ha assolutamente alcun modo di soddisfare facendo in modo che questa zona abbia pagine da usare scambiando, uccidendo altri processi o qualsiasi altro trucco, OOM-killer lo uccide.

Credo che ciò sia causato dalla mongolfiera della VM host all'avvio. Sui sistemi KVM, ci sono due valori che puoi impostare.

La memoria attuale
La memoria disponibile

Il modo in cui funziona è che puoi aggiungere memoria a caldo al tuo server fino alla memoria disponibile. Tuttavia, al sistema viene effettivamente fornita la memoria corrente.

Quando si avvia una VM KVM, inizia con la massima assegnazione di memoria possibile (la memoria disponibile). A poco a poco durante la fase di avvio del sistema KVM recupera questa memoria usando il suo ballooning, lasciandoti invece con l'impostazione di memoria corrente che hai.

È mia convinzione che sia successo qui. Linode ti consente di espandere la memoria, offrendoti molto di più all'avvio del sistema.

Ciò significa che esiste una Normal/HighMemzona all'inizio della vita del sistema. Quando l'hypervisor lo allontana, la zona normale scompare giustamente dal gestore della memoria. Ma ho il sospetto che l'impostazione della bandiera se questa zona è disponibile per l'allocazione non venga cancellata quando dovrebbe. Questo porta il kernel a tentare di allocare da una zona che non esiste.

In termini di risoluzione, hai due opzioni.

Visualizzalo nelle mailing list del kernel per vedere se si tratta davvero di un bug, comportamento previsto o niente a che fare con quello che sto dicendo.
Richiedere che linode imposti la 'memoria disponibile' sul sistema in modo che sia la stessa assegnazione di 1GiB della 'memoria corrente'. In questo modo il sistema non salta mai in mongolfiera e non ottiene mai una zona normale all'avvio, mantenendo chiara la bandiera. Buona fortuna a farglielo fare!

Dovresti essere in grado di provare che questo è il caso configurando la tua VM nell'impostazione KVM disponibile su 6GiB, corrente su 1GiB ed eseguendo il test usando lo stesso kernel per vedere se si verifica questo comportamento che vedi sopra. In tal caso, modificare l'impostazione "disponibile" in modo che sia uguale alla corrente di 1GiB e ripetere il test.

Sto facendo un sacco di ipotesi istruite qui e leggendo tra le righe un po 'per trovare questa risposta, ma quello che sto dicendo sembra adattarsi ai fatti già delineati.

Suggerisco di verificare la mia ipotesi e di farci conoscere tutti il risultato.

— Matthew Ife
fonte

4

Questa è una risposta completa (e ben spiegata)!

— Olivier Dulac il

2

Sì, risposta eccellente ... Molto più utile dei commenti delle persone secondo cui "l'OP dovrebbe fidarsi ciecamente dei messaggi del kernel" senza tentativi di spiegare perché lo spazio di scambio disponibile non viene utilizzato.

— Michael Martinez,

31

Per rispondere alla domanda del titolo, usa oom_score_adj(kernel> = 2.6.36) o per i kernel precedenti (> = 2.6.11) oom_adj, vedi man proc

/ proc / [pid] / oom_score_adj (dal Linux 2.6.36) Questo file può essere usato per regolare l'euristica cattiva usata per selezionare quale processo viene ucciso in condizioni di memoria insufficiente ...

/ proc / [pid] / oom_adj (dal Linux 2.6.11) Questo file può essere usato per regolare il punteggio usato per selezionare quale processo dovrebbe essere ucciso in una situazione di memoria insufficiente (OOM) ...

C'è molto altro da leggere ma impostare oom_score_adj su -1000 o oom_adj su -17 otterrà ciò che desideri.

Il problema è che qualcos'altro verrà ucciso. Forse sarebbe meglio determinare perché OOM viene invocato e affrontarlo.

— user9517 supporta GoFundMonica
fonte

4

+1 per "risolvi il problema di fondo". È possibile che il software offensivo (o qualcos'altro) abbia appena provato a sminuire un grosso pezzo di core? Sono richieste di più memoria, che porteranno le cose in territorio di allerta rossa, che tendono ad innescare il killer OOM.

— MadHatter supporta Monica

11

@Coder: I programmatori del kernel Linux e il kernel Linux conoscono chiaramente più di te. Il tuo processo è stato ucciso perché (nonostante le tue proteste) la memoria era insufficiente. Se ritieni che ciò non sia corretto, invia una segnalazione di bug . Se non ascolterai ciò che le persone chiaramente informate hanno da dire, forse dovresti pagare per il tuo sostegno perché i consigli valgono quello che paghi per questo. Il consiglio non sarà diverso ma lo avrai pagato, quindi lo apprezzerai di più.

— user9517 supporta GoFundMonica

4

@Coder Non sono un programmatore, purtroppo. È solo quello intercettato tra due possibilità: che il kernel non sa come usare la VM e che un programmatore ha commesso un errore, so su quale sono i miei soldi.

— MadHatter supporta Monica

1

@coder Sono il "qualcuno". Fammi sapere come mettermi in contatto.

— Matthew Ife

1

@MadHatter dall'esecuzione di migliaia di sistemi Linux posso dirti: NON è il caso che si possa presumere che non ci siano problemi nella gestione della memoria o in qualsiasi altra parte del kernel. Questo non è come una piattaforma ad alto grado di UNIX e, mentre tutto quello che normalmente funziona bene è non è ragionevole prendere entrambi i lati in alcun modo dogmatico.

— Florian Heigl,

12

Diversi pensieri (dai miei commenti sopra) e collegamenti a letture di interesse sulla tua situazione:

Ti consiglio di verificare che 1) puoi indirizzare più di 3Gb con il tuo attuale kernel & config (& cpu) [perché se 3Gb è un limite per il tuo sistema e sistema operativo, lo stai superando]. 2) di consentire lo scambio e il sottosistema di scambio è attivo e funzionante. buona fortuna (non spiegherò come, poiché dipende dalle tue impostazioni e specifiche. I motori di ricerca ti aiuteranno). E che non stai traboccando una tabella del kernel (nb di pid? O qualsiasi altra cosa (alcuni possono essere impostati al momento della compilazione del kernel).
Verifica che l'intera cosa (hardware o hardware simulato di VM, ecc.) Sia a 64 bit. (vedi ad esempio: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Il sistema operativo cpu e host e il sottosistema vm e il sistema operativo vm dovrebbero essere tutti abilitati a 64 bit, altrimenti non avrai un vero vm a 64 bit
Alcune buone letture:
- Come diagnosticare le cause dei processi di uccisione dei killer : in questo stesso sito. Fornisce un bel link, http://linux-mm.org/OOM_Killer , e un altro utente introduce lo strumento in cima, che potrebbe aiutare a diagnosticare cosa succede
- https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 mostra l'albero delle decisioni per la OOM (di una versione precedente, quindi ymmv. Leggi la fonte ^^)
- https://lwn.net/Articles/317814/ : "Taming the OOM killer" mostra, tra le altre cose, come creare un gruppo "invicible" e inserirvi il processo
- http://eloquence.marxmeier.com/sdb/html/linux_limits.html : mostra alcuni limiti comuni del kernel
- http://win.tue.nl/~aeb/linux/lk/lk-9.html : è una buona lettura (spazio sprecato con alcuni metodi di allocazione, ecc.) anche se è davvero datato (e quindi indirizza solo 32- architetture bit ...)
- http://bl0rg.krunch.be/oom-frag.html mostra alcuni motivi per cui "Il killer OOM può essere chiamato anche quando c'è ancora molta memoria disponibile"
- https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : offre un modo per verificare come il sistema assegna la memoria
- https://serverfault.com/a/724518/146493 : risposta eccellente che fornisce un modo dettagliato per sapere davvero cosa è successo (ma ... ha mirato a una domanda a 32 bit, quindi ymmv. Comunque una lettura e una risposta incredibili, comunque).
e infine: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html mostra un modo per impedire che il tuo processo venga preso di mira dall'omicida! ( echo -17 > /proc/PROCESSPID/oom_adj). Potrebbe essere soggetto a cambiamenti e potrebbe essere una brutta cosa (causare altri tipi di guasti in quanto il sistema ora non può semplicemente uccidere l'offensore principale ...) Usare con cautela. @iain nota che "oom_adj" è per i kernel più vecchi e dovrebbe essere sostituito da "oom_score_adj" in quelli più recenti. Grazie, Iain)

— Olivier Dulac
fonte

1

oom_adj è valido solo per i kernel più vecchi, quelli più recenti usano oom_score_adj.

— user9517 supporta GoFundMonica

disclaimer: non posso fornire più informazioni dettagliate rispetto ai pochi link sopra, dato che al momento non riesco ad accedere a un sistema Linux ... e ci sono così tante cose da controllare. Forse qualcuno interverrà e fornirà belle procedure passo-passo ... (la risposta del serverfault, ultimo del link "buone letture" nella mia risposta, è stata così ed è una lettura incredibile.)

— Olivier Dulac

6

accanto oom_score_adjall'aumento menzionato per il processo in questione (che probabilmente non aiuterà molto - renderebbe meno probabile che quel processo venga ucciso PRIMA, ma dato che è solo un sistema di processo ad alta intensità di memoria probabilmente non si riprenderà fino a quando non sarà finalmente ucciso), ecco alcune idee da modificare:

se imposti vm.overcommit_memory=2, modifica anche vm.overcommit_ratioforse 90 (in alternativa, imposta vm.overcommit_memory=0- vedi i documenti di overcommit del kernel )
aumentare vm.min_free_kbytesal fine di mantenere sempre un po 'di RAM fisica libera e quindi ridurre le possibilità di OOM che ha bisogno di uccidere qualcosa (ma non esagerare, come OOM all'istante).
aumentare vm.swappinessa 100 (per rendere più facile lo scambio del kernel )

Si noti che se si dispone di memoria insufficiente per eseguire l'attività a portata di mano, anche se non si esegue la OOM, potrebbe (o meno) diventare ESTREMAMENTE lento - un lavoro di mezz'ora (sul sistema con RAM sufficiente) può richiedere diverse settimane ( quando la RAM viene sostituita con swap) per il completamento in casi estremi o addirittura per bloccare l'intera VM. Ciò è particolarmente vero se lo swap è su dischi rotazionali classici (al contrario degli SSD) a causa di enormi letture / scritture casuali che sono molto costose per loro.

— Matija Nalis
fonte

3

Vorrei provare a abilitare il sovraccarico e vedere se questo aiuta. Il tuo processo sembra fallire all'interno di una forkchiamata, che richiede tutta la memoria virtuale del processo iniziale. overcommit_memory=2non rende il tuo processo immune al killer OOM, impedisce semplicemente al tuo processo di attivarlo allocando troppo. Altri processi possono produrre errori di allocazione non correlati (ad es. Ottenere un blocco di memoria contiguo), che comunque attivano il killer OOM e eliminano il processo.

In alternativa (e altro ancora al punto), come suggeriscono diversi commenti, acquistare più RAM.

— Dmitry Grigoryev
fonte

0

Breve storia: prova una versione del kernel diversa. Ho un sistema che mostrava errori OOM con kernel 4.2.0-x e 4.4.0-x, ma non con 3.19.0-x.

Per farla breve: (non troppo!) Ho un Compaq DC5000 ancora in servizio qui - attualmente con 512 MB di RAM (e una parte di questo, come 32-128 MB, che viene data al video di bordo ..) NFS, ho un monitor collegato ad esso, quindi ogni tanto accedo ad esso (Ubuntu Classic, no Unity.)

Tramite Ubuntu HWE stavo eseguendo il kernel 3.19.x per un bel po '; finirebbe per scambiarsi come 200-300 MB di roba, ma apparentemente era roba inutilizzata, non ci sarebbe stata alcuna attività di scambio da doverlo scambiare in seguito, per quanto potevo dire.

4.2.0-x kernel e ora 4.4.0-x kernel, posso avviare una grossa scrittura NFS su di esso, solo 220 MB nello scambio (cioè 1,3 GB gratuiti), e inizierà OOM a uccidere le cose. Non pretenderò se si tratta di un bug del kernel o di un "problema di ottimizzazione" (come una riserva di 64 MB che va normalmente bene, ma troppo alta su un sistema di ~ 400 MB o giù di lì?)

Non mancare di rispetto a coloro che stanno dicendo che si sta in qualche modo rompendo solo perché si aspetta di usare lo swap; con tutto il rispetto ti sbagli. Non sarà veloce, ma ero solito passare 1 o 2 GB nello scambio su alcuni sistemi da 512 MB-1 GB. Naturalmente alcuni tipi di software sono un po 'di RAM, ma nel mio caso (dato che sto eseguendo lo stesso software solo su un kernel diverso), questo non è chiaramente il caso.

— user367995
fonte