OOM asesino matando cosas con un montón (?) De RAM libre

El asesino OOM parece estar matando cosas a pesar de tener más que suficiente RAM libre en mi sistema:

Gráfico de utilización de memoria (Resolución completa)

Gráfico de utilización de IO (Resolución completa)

27 minutos y 408 procesos más tarde, el sistema comenzó a responder nuevamente. Lo reinicié aproximadamente una hora después, y poco después la utilización de la memoria volvió a la normalidad (para esta máquina).

Tras la inspección, tengo algunos procesos interesantes ejecutándose en mi caja:

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...]

Este servidor específico ha estado funcionando durante aprox. 8 horas, y estos son los únicos dos procesos que tienen esos ... valores impares. Mi sospecha es que "algo más" está sucediendo, potencialmente relevante para estos valores no sensoriales. En concreto, creo que el sistema cree que no tiene memoria, cuando en realidad no lo está. Después de todo, cree que rsyslogd está usando 55383984% de CPU de manera consistente, cuando el máximo teórico es de 400% en este sistema de todos modos.

Esta es una instalación de CentOS 6 totalmente actualizada (6.2) con 768 MB de RAM. ¡Le agradeceríamos cualquier sugerencia sobre cómo descubrir por qué sucede esto!

editar: adjuntar el vm. sysctl tunables ... He estado jugando con swappiness (hecho evidente por ser 100), y también estoy ejecutando un script absolutamente terrible que descarga mis buffers y caché (hecho evidente por vm.drop_caches siendo 3) + sincroniza el disco cada 15 minutos. Es por eso que después del reinicio, los datos almacenados en caché crecieron a un tamaño algo normal, pero luego volvieron a caer rápidamente. Reconozco que tener caché es algo muy bueno, pero hasta que lo resuelva ...

También algo interesante es que si bien mi archivo de paginación creció durante el evento, solo alcanzó ~ 20% de la utilización total posible, lo que no es característico de los verdaderos eventos de OOM. En el otro extremo del espectro, el disco se volvió completamente loco durante el mismo período, lo cual es característico de un evento OOM cuando el archivo de paginación está en juego.

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

editar: y adjuntando el primer mensaje OOM ... después de una inspección más cercana, dice que algo claramente se salió de su camino para comer la totalidad de mi espacio de intercambio también.

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

linux centos6 linode oom Kyle Brantley
fuente

¿Puede proporcionar la salida de sysctl -a 2>/dev/null | grep '^vm'?

Patrick

Adicional. Espero que usted (o alguien) pueda encontrar algo que me haya perdido.

Kyle Brantley

Lo único que me llama la overcommit_memoryatención es el entorno. Establecerlo en 1 no debería causar este comportamiento, pero nunca he tenido la necesidad de configurarlo para que 'siempre se comprometa demasiado' antes, por lo que no hay mucha experiencia allí. Mirando las otras notas que agregaste, dijiste que el intercambio solo se usó en un 20%. Sin embargo, según el volcado de registro de OOM, Free swap = 0kB. Definitivamente pensó que el intercambio se usaba al 100%.

Patrick

Respuestas:

Acabo de mirar el volcado de registro de Oom y cuestiono la precisión de ese gráfico. Observe la primera línea 'Nodo 0 DMA32'. Se dice free:3376kB, min:3448kBy low:4308kB. Siempre que el valor libre caiga por debajo del valor bajo, se supone que kswapd comenzará a intercambiar cosas hasta que ese valor vuelva a estar por encima del valor alto. Cada vez que la caída cae por debajo del mínimo, el sistema básicamente se congela hasta que el núcleo vuelve a subir por encima del valor mínimo. Ese mensaje también indica que el intercambio se usó por completo donde dice Free swap = 0kB.
Básicamente, kswapd se activó, pero el intercambio estaba lleno, por lo que no podía hacer nada, y el valor de pages_free todavía estaba por debajo del valor de pages_min, por lo que la única opción era comenzar a matar las cosas hasta que pudiera volver a las páginas.
Definitivamente te quedaste sin memoria.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html tiene una muy buena explicación de cómo funciona. Consulte la sección 'Implementación' en la parte inferior.

Patricio
fuente

Con esto, el OP realmente simplemente necesita más memoria RAM ...

ewwhite

más carnero, o averigua qué se lo come.

Patrick

Puse las líneas en ese gráfico con mucha precisión. Dejó de registrar datos ~ 1-2m antes de que se cancelara el primer proceso, y reanudó los datos de registro ~ 4-5m después de que se matara el último. En este punto, apuesto a que algún proceso se volvió completamente loco y comenzó a sacudir mi archivo de paginación: una vez que finalmente lo consiguió, eliminó los procesos que también se estaban ejecutando funcionalmente, razón por la cual cuando los datos regresaron, el archivo de paginación estaba elevado pero no lleno. ¡Las sugerencias sobre cómo determinar qué está haciendo esto serían bienvenidas!

Kyle Brantley

@KyleBrantley ¿Qué valores estás sacando para generar el gráfico? Una de las desventajas del sistema de memoria virtual de Linux es que no existe una definición concreta de "libre". Hay una docena de formas de definir 'memoria libre'. El que importa en lo que respecta a kswapd es el valor de pages_free. En cuanto al intercambio gratuito, no sé qué valor podría estar leyendo que estaría tan lejos. La única forma de ver realmente qué está comiendo la memoria es registrar instantáneas continuas de todos los procesos en la caja y ver qué está usando toda la memoria cuando el asesino de Oom comienza a volverse loco.

Patrick

Sí, se me acabó la memoria. Terminé hurgando en los registros para descubrir que mis procesos secundarios de apache se estaban bloqueando repetidamente, lo que me llevó a darme cuenta de que tenía procesos secundarios funcionalmente infinitos que podrían comenzar. Todo lo que se necesitó fue que los robots automatizados de blogspam lanzaran muchas solicitudes / segundo al host para que se cayera. Ajustar apache resolvió todo.

Kyle Brantley

Deshágase del script drop_caches. Además, debe publicar las partes relevantes de su dmesgy /var/log/messagessalida mostrando los mensajes OOM.

Sin embargo, para detener este comportamiento, recomendaría probar este sysctlsintonizable. Este es un sistema RHEL / CentOS 6 y se ejecuta claramente en recursos limitados. ¿Es una máquina virtual?

Intente modificar /proc/sys/vm/nr_hugepagesy ver si los problemas persisten. Esto podría ser un problema de fragmentación de memoria, pero vea si esta configuración hace la diferencia. Para que el cambio sea permanente, agréguelo vm.nr_hugepages = valuea su /etc/sysctl.confy ejecute sysctl -ppara releer el archivo de configuración ...

Ver también: Interpretar mensajes de "error de asignación de página" del núcleo críptico

ewwhite
fuente

Se agregó el primer mensaje de Oom-Killer. Si bien MySQL es lo más intensivo en RAM que estoy ejecutando, lo he ajustado para no abrumar la caja tampoco, por lo que, aparte de los valores locos que estoy viendo en la parte superior, realmente no lo sospecho (5.1% el uso de memoria está bien, considerando todas las cosas). Es un VPS, con 768MB de RAM. Lo leeré en nr_hugepages y lo intentaré, ¡gracias!

Kyle Brantley

@ewwhite asignando que muchas páginas enormes matarían la caja. La caja solo tiene 768 MB de RAM, y con el valor predeterminado de las páginas enormes de 2 MB, eso asignaría 2 GB de páginas enormes. La caja no podría manejar eso e inmediatamente moriría.

Patrick

Actualizado. Sin embargo, el valor debe incrementarse desde cero.

ewwhite

Es aún más complicado que eso. Debe establecer los permisos de páginas enormes, y mysql debe configurarse para usar páginas enormes, de lo contrario, simplemente los está asignando sin razón alguna.

Patrick

No hay datos disponibles en el gráfico desde que el asesino OOM comienza hasta que termina. Creo en el período de tiempo en que se interrumpe el gráfico que, de hecho, el consumo de memoria aumenta y ya no hay memoria disponible. De lo contrario, el asesino OOM no se utilizaría. Si observa el gráfico de memoria libre después de que el asesino OOM se haya detenido, puede ver que disminuye desde un valor más alto que antes. Al menos hizo su trabajo correctamente, liberando memoria.

Tenga en cuenta que su espacio de intercambio se utiliza casi por completo hasta que se reinicie. Eso casi nunca es bueno y una señal segura de que queda poca memoria libre.

La razón por la que no hay datos disponibles para ese período de tiempo en particular es porque el sistema está demasiado ocupado con otras cosas. Los valores "divertidos" en su lista de procesos pueden ser solo un resultado, no una causa. No es inaudito.

Verifique /var/log/kern.log y / var / log / messages, ¿qué información puede encontrar allí?

Si el registro también se detuvo, intente otras cosas, voltee la lista de procesos en un archivo cada segundo más o menos, lo mismo con la información de rendimiento del sistema. Ejecútelo con alta prioridad para que aún pueda hacer su trabajo (con suerte) cuando la carga aumenta. Aunque si no tiene un núcleo de preferencia (a veces indicado como un núcleo de "servidor") puede que no tenga suerte en ese sentido.

Creo que encontrará que los procesos que están utilizando la mayor cantidad de CPU en el momento en que comienzan sus problemas son la causa. Nunca he visto rsyslogd ni mysql comportándose de esa manera. Los culpables más probables son las aplicaciones Java y las aplicaciones guiadas por GUI, como un navegador.

aseq
fuente

No hay datos en esa brecha porque la carga en la caja aumenta de manera tan absurda que todo, incluido el agente de monitoreo, se detiene por completo. El agente en sí nunca fue asesinado durante el período cercano a la muerte, pero tampoco pudo informar ningún dato. Mi espacio de intercambio estaba realmente bien. Estaba usando ~ 130 / 512MB en total antes del reinicio. rsyslogd está configurado para informar registros a una ubicación de red, donde se registró todo lo que sucedió, y aparte de matar 408 procesos (algunos de los cuales fueron niños apache que se reiniciaron), nada se destacó.

Kyle Brantley

Puedo terminar volcando la lista completa de procesos en un archivo (o en la red) cada pocos segundos si no puedo entender lo que está sucediendo aquí, así que gracias por la buena idea.

Kyle Brantley

Sí, debe hacer eso, asegúrese de registrar también el uso de CPU de cada proceso, eche un vistazo a "top -b" (modo por lotes). El proceso que los picos podría ser el culpable.

aseq