OOM killer uccide le cose con molta (?) RAM libera

Il killer OOM sembra stia uccidendo le cose nonostante abbia RAM più che sufficiente sul mio sistema:

Grafico di utilizzo della memoria (Piena risoluzione)

Grafico di utilizzo IO (Piena risoluzione)

27 minuti e 408 processi dopo, il sistema ha ripreso a rispondere. L'ho riavviato circa un'ora dopo e subito dopo l'utilizzo della memoria è tornato alla normalità (per questa macchina).

All'ispezione, ho alcuni processi interessanti in esecuzione sulla mia scatola:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

Questo server specifico è in esecuzione da ca. 8 ore e questi sono gli unici due processi che hanno tali ... valori dispari. Il mio sospetto è che stia succedendo "qualcos'altro", potenzialmente rilevante per questi valori insensati. In particolare, penso che il sistema pensi che sia senza memoria, quando in realtà non lo è. Dopotutto, pensa che rsyslogd stia usando costantemente la CPU del 55383984%, quando il massimo teorico è comunque del 400% su questo sistema.

Questa è un'installazione CentOS 6 completamente aggiornata (6.2) con 768 MB di RAM. Qualche suggerimento su come capire perché questo accada sarebbe apprezzato!

modifica: allegando la vm. sintonizzatori di sistema .. Ho giocato con swappiness (reso evidente dal fatto che è 100), e sto anche eseguendo uno script assolutamente terribile che scarica i miei buffer e cache (reso evidente da vm.drop_caches essendo 3) + sincronizza il disco ogni 15 minuti. Questo è il motivo per cui, dopo il riavvio, i dati memorizzati nella cache sono cresciuti in una dimensione un po 'normale, ma poi sono rapidamente ricaduti. Riconosco che avere cache è una cosa molto buona, ma fino a quando non lo capirò ...

Inoltre, un po 'interessante è che mentre il mio file di paging è cresciuto durante l'evento, ha raggiunto solo il 20% circa dell'utilizzo totale possibile, il che è insolito per i veri eventi OOM. All'altra estremità dello spettro, il disco è andato assolutamente fuori di testa durante lo stesso periodo, caratteristica di un evento OOM quando il file di paging è in riproduzione.

sysctl -a 2>/dev/null | grep '^vm':

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

modifica: e allegando il primo messaggio OOM ... a un esame più attento, sta dicendo che qualcosa chiaramente ha fatto di tutto per mangiare tutto il mio spazio di scambio.

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

— Kyle Brantley
fonte

Potete fornire l'output di sysctl -a 2>/dev/null | grep '^vm'?

— Patrick,

Aggiunto. Spero che tu (o qualcuno) possa trovare qualcosa che mi è mancato.

— Kyle Brantley,

L'unica cosa che mi salta addosso è l' overcommit_memoryambientazione. Impostarlo su 1 non dovrebbe causare questo comportamento, ma non ho mai avuto la necessità di impostarlo su "sovraccarico sempre" prima, quindi non molta esperienza lì. Osservando le altre note che hai aggiunto, hai affermato che lo swap è stato utilizzato solo al 20%. Tuttavia secondo l'OOM discarica di registro, Free swap = 0kB. Ha sicuramente pensato che lo swap fosse usato al 100%.

— Patrick,

Risposte:

Ho appena guardato il dump del registro oom e metto in dubbio l'accuratezza di quel grafico. Si noti la prima riga "Nodo 0 DMA32". Si dice free:3376kB, min:3448kBe low:4308kB. Ogni volta che il valore libero scende al di sotto del valore basso, kswapd dovrebbe iniziare a scambiare le cose fino a quando quel valore non torna al di sopra del valore alto. Ogni volta che il free scende al di sotto di min, il sistema praticamente si blocca fino a quando il kernel non lo ripristina al di sopra del valore minimo. Quel messaggio indica anche che lo swap è stato completamente usato dove dice Free swap = 0kB.
Quindi in pratica kswapd è stato attivato, ma lo swap era pieno, quindi non poteva fare nulla e il valore pages_free era ancora inferiore al valore pages_min, quindi l'unica opzione era iniziare a uccidere le cose fino a quando non si potesse ripristinare il backup di pages_free.
Hai sicuramente esaurito la memoria.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html ha una spiegazione davvero valida di come funziona. Vedi la sezione "Implementazione" in fondo.

— Patrick
fonte

Quindi l'OP ha davvero bisogno di più RAM ...

— ewwhite,

più ram, o scopri cosa lo mangia.

— Patrick,

Ho messo le linee su quel grafico in modo molto preciso. Ha interrotto la registrazione dei dati ~ 1-2 m prima che il primo processo venisse interrotto e ha ripreso i dati di registrazione ~ 4-5 m dopo che l'ultimo è stato ucciso. A questo punto, sto scommettendo che alcuni processi sono andati assolutamente in tilt e hanno iniziato a distruggere il mio file di paging: una volta che ha finalmente ottenuto tutto, ha ucciso anche i processi che funzionavano funzionalmente anche dal file di paging, motivo per cui quando sono tornati i dati, il file di paging era elevato ma non pieno. Suggerimenti su come determinare cosa sta facendo questo sarebbero i benvenuti!

— Kyle Brantley,

@KyleBrantley Quali valori stai tirando per generare il grafico? Uno degli svantaggi del sistema di memoria virtuale di Linux è che non esiste una definizione concreta di "libero". Esistono una dozzina di modi per definire la "memoria libera". Quello che conta per quanto riguarda kswapd è il valore pages_free. Per quanto riguarda lo swap gratuito, non so quale valore potresti leggere quale sarebbe così lontano. L'unico modo per vedere davvero ciò che sta mangiando la memoria è la registrazione di istantanee continue di tutti i processi sulla scatola e vedere cosa sta consumando tutta la memoria quando il killer di Oom inizia a impazzire.

— Patrick,

Sì, ho esaurito la memoria. Sono finito a scorrere tra i tronchi per scoprire che i miei processi figlio apache venivano ripetutamente uccisi, il che mi ha portato a capire che avevo processi figlio funzionalmente infiniti che poteva iniziare. Sono bastati i robot di blogspam automatici che lanciavano molte richieste / secondo all'host affinché cadesse. La modifica dell'apache ha risolto tutto.

— Kyle Brantley,

Sbarazzati dello script drop_caches. Inoltre, dovresti pubblicare le parti pertinenti del tuo dmesge /var/log/messagesdell'output che mostrano i messaggi OOM.

Per interrompere questo comportamento, tuttavia, consiglierei di provare questo sysctlparametro sintonizzabile. Questo è un sistema RHEL / CentOS 6 ed è chiaramente in esecuzione su risorse limitate. È una macchina virtuale?

Prova a modificare /proc/sys/vm/nr_hugepagese vedi se i problemi persistono. Questo potrebbe essere un problema di frammentazione della memoria, ma vedi se questa impostazione fa la differenza. Per rendere permanente la modifica, aggiungi vm.nr_hugepages = valueal tuo /etc/sysctl.confed esegui sysctl -pper rileggere il file di configurazione ...

Vedi anche: Interpretazione dei messaggi di "allocazione di pagina" del kernel criptico

— ewwhite
fonte

Aggiunto il primo messaggio oom-killer. Mentre MySQL è la cosa più intensiva della RAM che sto eseguendo, l'ho sintonizzato per non sovraccaricare la scatola, quindi a parte i valori folli che sto vedendo in alto, non lo sospetto davvero (5.1% l'utilizzo della memoria va bene, tutto sommato). È un VPS, con 768 MB di RAM. Leggerò sul nr_hugepages e ci proverò, grazie!

— Kyle Brantley,

@ewwhite ha assegnato che molti hugepage avrebbero ucciso la scatola. La scatola ha solo ram da 768 MB, e con il valore predefinito di hugepagesz di 2 mb, che assegnerebbe 2 gb di hugepage. La scatola non sarebbe in grado di gestirlo e morirà immediatamente.

— Patrick,

Aggiornato. Tuttavia, il valore dovrebbe essere aumentato da zero.

— ewwhite,

È ancora più complicato di così. Devi impostare le autorizzazioni per le pagine enormi, e mysql deve essere configurato per utilizzare pagine enormi, altrimenti dovrai semplicemente allocarle senza motivo.

— Patrick,

Non ci sono dati disponibili sul grafico da quando il killer OOM inizia fino alla fine. Credo nel lasso di tempo in cui il grafico è interrotto che in effetti il consumo di memoria aumenta e non c'è più memoria disponibile. Altrimenti il killer OOM non verrebbe usato. Se guardi il grafico della memoria libera dopo che il killer OOM si è fermato, puoi vedere che scende da un valore più alto di prima. Almeno ha fatto il suo lavoro correttamente, liberando memoria.

Si noti che lo spazio di swap è quasi completamente utilizzato fino al riavvio. Non è quasi mai una buona cosa e un segno sicuro è rimasta poca memoria libera.

Il motivo per cui non ci sono dati disponibili per quel particolare periodo di tempo è perché il sistema è troppo occupato con altre cose. I valori "divertenti" nell'elenco dei processi potrebbero essere solo un risultato, non una causa. Non è inaudito.

Controlla /var/log/kern.log e / var / log / messages, quali informazioni puoi trovare lì?

Se anche la registrazione si è interrotta, provare altre cose, scaricare l'elenco dei processi su un file ogni secondo circa, lo stesso con le informazioni sulle prestazioni del sistema. Eseguilo con priorità alta in modo che possa ancora fare il suo lavoro (si spera) quando il carico aumenta. Sebbene se non si dispone di un kernel preempt (a volte indicato come kernel "server"), si può essere sfortunati in questo senso.

Penso che scoprirai che il (i) processo (i) che sta usando la maggior parte della CPU nel momento in cui iniziano i tuoi problemi è (sono) la causa. Non ho mai visto rsyslogd né mysql comportarsi in quel modo. I colpevoli più probabili sono app java e app guidate da gui come un browser.

— ASEQ
fonte

Non ci sono dati in questa lacuna perché il carico sulla scatola è così assurdamente alto che tutto, compreso l'agente di monitoraggio, si ferma completamente. L'agente stesso non è mai stato effettivamente ucciso durante il periodo di pre-morte, ma non è stato in grado di riportare alcun dato. Il mio spazio di swap in realtà andava bene. Prima del riavvio utilizzava un totale di ~ 130/512 MB. rsyslogd è configurato per riportare i log in un percorso di rete, dove è stato registrato tutto ciò che è accaduto - e oltre a esso ha ucciso 408 processi (alcuni dei quali erano bambini Apache che sono stati riavviati), nulla si è distinto.

— Kyle Brantley,

Potrei finire scaricando l'elenco completo dei processi su un file (o sulla rete) ogni pochi secondi se non riesco davvero a capire cosa sta succedendo qui, quindi grazie per la buona idea.

— Kyle Brantley,

Sì, dovresti farlo, assicurati di registrare anche l'utilizzo della CPU di ogni processo, dai un'occhiata a "top -b" (modalità batch). Il processo che picchi potrebbe essere il colpevole.

— aseq