update nucleo last know kernels descargar como linux-kernel redis fork

linux-kernel - nucleo - linux kernel version



redis bgsave falló porque la bifurcación no puede asignar memoria (3)

De las páginas de manual de proc (5) :

/ proc / sys / vm / overcommit_memory

Este archivo contiene el modo de contabilidad de la memoria virtual del kernel. Los valores son:

0: overcommit heurístico (este es el valor predeterminado)

1: siempre exagerar, nunca comprobar

2: siempre verifica, nunca exageres

En el modo 0, las llamadas de mmap (2) con el conjunto MAP_NORESERVE no se verifican, y la verificación predeterminada es muy débil, lo que conlleva el riesgo de que el proceso se "elimine por OOM". Bajo Linux 2.4, cualquier valor que no sea cero implica el modo 1. En el modo 2 (disponible desde Linux 2.6), el espacio total de direcciones virtuales en el sistema está limitado a (SS + RAM * (r / 100)), donde SS es el tamaño del espacio de intercambio, y la RAM es el tamaño de la memoria física, y r es el contenido del archivo / proc / sys / vm / overcommit_ratio.

todo: aquí está la información de la memoria de mi servidor con ''free -m''

total used free shared buffers cached Mem: 64433 49259 15174 0 3 31 -/+ buffers/cache: 49224 15209 Swap: 8197 184 8012

mi redis-server ha usado 46G de memoria, queda casi 15G de memoria libre

Como sé, la bifurcación es copia en escritura, no debería fallar cuando hay 15G de memoria libre, lo que es suficiente para malloc estructuras de kernel necesarias.

además, cuando redis-server usó memoria 42G, bgsave está bien y la bifurcación también está bien.

¿Hay algún parámetro de vm que pueda sintonizar para que el retorno de la horquilla tenga éxito?

Gracias.


Más específicamente, de las preguntas frecuentes de Redis

El esquema de ahorro de fondo de Redis se basa en la semántica de copia en escritura de los sistemas operativos modernos: la redis forks (crea un proceso secundario) que es una copia exacta del padre. El proceso hijo vuelca el DB en el disco y finalmente sale. En teoría, el niño debería usar tanta memoria como el padre como copia, pero en realidad, gracias a la semántica de copia en escritura implementada por la mayoría de los sistemas operativos modernos, el proceso padre e hijo compartirán las páginas de la memoria común. Una página se duplicará solo cuando cambie en el elemento secundario o en el principal. Como en teoría todas las páginas pueden cambiar mientras el proceso secundario se está guardando, Linux no puede saber de antemano cuánta memoria tomará el niño, por lo que si la configuración de overcommit_memory se establece en cero, la bifurcación fallará a menos que haya tanta RAM libre como se requiere para duplicar realmente todas las páginas de memoria principal, con el resultado de que si tiene un conjunto de datos Redis de 3 GB y solo 2 GB de memoria libre, se producirá un error.

Establecer overcommit_memory en 1 dice que Linux se relajará y ejecutará la bifurcación en una forma de asignación más optimista, y esto es realmente lo que desea para Redis.

Redis no necesita tanta memoria como el sistema operativo cree que hace para escribir en el disco, por lo que puede fallar preventivamente la bifurcación.


Modifique /etc/sysctl.conf y agregue:

vm.overcommit_memory=1

Luego reinicie sysctl con:

En FreeBSD:

sudo /etc/rc.d/sysctl reload

En Linux:

sudo sysctl -p /etc/sysctl.conf