Phenquestions
¿Cómo vm.min_free_kbytes funciona
Es posible que el sistema necesite asignaciones de memoria para garantizar el funcionamiento adecuado del propio sistema. Si el kernel permite que se asigne toda la memoria, podría tener problemas cuando necesite memoria para las operaciones regulares para mantener el sistema operativo funcionando sin problemas. Es por eso que el kernel proporciona la vm tunable.min_free_kbytes. El ajuste forzará al administrador de memoria del kernel a mantener al menos X cantidad de memoria libre. Aquí está la definición oficial del documentación del kernel de linux: "Esto se usa para forzar a la VM Linux a mantener una cantidad mínima de kilobytes libres. La VM usa este número para calcular un valor de marca de agua [WMARK_MIN] para cada zona de baja memoria en el sistema. Cada zona de baja memoria obtiene una cantidad de páginas gratuitas reservadas en función de su tamaño. Se necesita una cantidad mínima de memoria para satisfacer las asignaciones de PF_MEMALLOC; Si lo configura en menos de 1024 KB, su sistema se romperá sutilmente y será propenso a bloquearse bajo cargas elevadas. Configurar esto demasiado alto hará que su máquina OOM instantáneamente."
Validando vm.min_free_kbytes Obras
Para probar que la configuración de min_free_kbytes funciona según lo diseñado, he creado una instancia virtual de Linux con solo 3.75 GB de RAM. Utilice el siguiente comando gratuito para analizar el sistema:
# libre -m
Mirando la utilidad de memoria libre anterior usando el indicador -m para tener los valores impresos en MB. La memoria total es 3.5 a 3.75 GB de memoria. Se utilizan 121 MB de memoria, 3.3 GB de memoria son libres, 251 MB son usados por la caché del búfer. Y 3.3 GB de memoria disponible.
Ahora vamos a cambiar el valor de vm.min_free_kbytes y vea cuál es el impacto en la memoria del sistema. Haremos eco del nuevo valor en el sistema de archivos virtual proc para cambiar el valor del parámetro del kernel como se muestra a continuación:
# echo 1500000> / proc / sys / vm / min_free_kbytes# sysctl vm.min_free_kbytes
Puede ver que el parámetro se cambió a 1.5 GB aproximadamente y ha entrado en vigor. Ahora usemos el libre comando de nuevo para ver los cambios reconocidos por el sistema.
# libre -m
El comando no modifica la memoria libre ni la caché del búfer, pero la cantidad de memoria se muestra como disponible se ha reducido de 3327 a 1222 MB. Que es una reducción aproximada del cambio en el parámetro a 1.5 GB de memoria libre como mínimo.
Ahora creemos un archivo de datos de 2GB y luego veamos qué hace la lectura de ese archivo en la memoria caché del búfer con los valores. Aquí se explica cómo crear un archivo de datos de 2GB en 2 líneas de script bash a continuación. El script generará un archivo aleatorio de 35 MB usando el comando dd y luego lo copiará 70 veces en un nuevo archivo de datos producción:
# dd if = / dev / random of = / root / d1.recuento de txt = 1000000# para i en 'seq 1 70'; echo $ i; gato / raíz / d1.txt >> / root / archivo_datos; hecho
Leamos el archivo e ignoremos el contenido leyendo y redirigiendo el archivo a / dev / null como se indica a continuación:
# cat archivo_de_datos> / dev / nullOk, qué le ha pasado a la memoria de nuestro sistema con este conjunto de maniobras, comprobémoslo ahora:
# libre -m
Analizando los resultados anteriores. Todavía tenemos 1.8 GB de memoria libre para que el kernel haya protegido una gran parte de la memoria como reservada debido a nuestra configuración min_free_kbytes. La caché del búfer ha usado 1691 MB, que es menos que el tamaño total de nuestro archivo de datos, que es 2.3 GB. Aparentemente todo el archivo de datos no se pudo almacenar en el caché debido a la falta de memoria disponible para usar en el caché del búfer. Podemos validar que el archivo completo no está almacenado en la caché, sino cronometrando los intentos repetidos de leer el archivo. Si estuviera en caché, tardaría una fracción de segundo en leer el archivo. Vamos a intentarlo.
# time cat archivo_de_datos> / dev / null# time cat archivo_de_datos> / dev / null
La lectura del archivo tardó casi 20 segundos, lo que implica que es casi seguro que no todo esté almacenado en caché.
Como validación final, reduzcamos la máquina virtual.min_free_kbytes para permitir que la caché de la página tenga más espacio para operar y podemos esperar que la caché funcione y la lectura del archivo sea mucho más rápida.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat archivo_de_datos> / dev / null
# time cat archivo_de_datos> / dev / null
Con la memoria adicional disponible para el almacenamiento en caché, el tiempo de lectura del archivo se redujo de 20 segundos antes a .364 segundos con todo en caché.
Tengo curiosidad por hacer otro experimento. ¿Qué sucede con las llamadas malloc para asignar memoria desde un programa en C frente a este vm realmente alto?.Configuración de min_free_kbytes. ¿Le fallará al malloc?? ¿Morirá el sistema?? Primero reinicie el vm.min_free_kbytes configurando el valor realmente alto para reanudar nuestros experimentos:
# echo 1500000> / proc / sys / vm / min_free_kbytesVeamos nuevamente nuestra memoria libre:
Teóricamente tenemos 1.9 GB libres y 515 MB disponibles. Usemos un programa de prueba de esfuerzo llamado stress-ng para usar algo de memoria y ver dónde fallamos. Usaremos el probador vm e intentaremos asignar 1 GB de memoria. Como solo hemos reservado 1.5 GB en un 3.Sistema de 75 GB, supongo que esto debería funcionar.
# stress-ng --vm 1 --vm-bytes 1G --timeout 60sstress-ng: info: [17537] despachando cerdos: 1 vm
stress-ng: información: [17537] asignación de caché: tamaño de caché predeterminado: 46080K
stress-ng: info: [17537] ejecución exitosa completada en 60.09s (1 min, 0.09 segundos)
# stress-ng --vm 2 --vm-bytes 1G --timeout 60s
# stress-ng --vm 3 --vm-bytes 1G --timeout 60s
Intentémoslo de nuevo con más trabajadores, podemos probar con 1, 2, 3, 4 trabajadores y en algún momento debería fallar. En mi prueba pasó con 1 y 2 trabajadores pero falló con 3 trabajadores.
Reiniciemos la vm.min_free_kbytes a un número bajo y ver si eso nos ayuda a ejecutar 3 factores de estrés de memoria con 1 GB cada uno en un 3.Sistema de 75GB.
# echo 67584> / proc / sys / vm / min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G --timeout 60s
Esta vez funcionó con éxito sin errores, lo probé dos veces sin problemas. Entonces puedo concluir que hay una diferencia de comportamiento de tener más memoria disponible para malloc, cuando la máquina virtual.El valor min_free_kbytes se establece en un valor más bajo.
Configuración predeterminada para vm.min_free_kbytes
El valor predeterminado para la configuración en mi sistema es 67584, que es aproximadamente 1.8% de RAM en el sistema o 64 MB. Por razones de seguridad en un sistema muy maltratado, tendería a aumentarlo un poco quizás a 128 MB para permitir más memoria libre reservada, sin embargo, para el uso promedio, el valor predeterminado parece lo suficientemente sensato. La documentación oficial advierte sobre hacer que el valor sea demasiado alto. Establecerlo en 5 o 10% de la RAM del sistema probablemente no sea el uso previsto de la configuración y es demasiado alto.
Configuración de vm.min_free_kbytes para sobrevivir a los reinicios
Para asegurarse de que la configuración pueda sobrevivir a los reinicios y no se restaure a los valores predeterminados al reiniciar, asegúrese de hacer que la configuración de sysctl sea persistente colocando el nuevo valor deseado en / etc / sysctl.conf archivo.
Conclusión
Hemos visto que la vm.min_free_kbytes linux kernel tunable se puede modificar y puede reservar memoria en el sistema para garantizar que el sistema sea más estable, especialmente durante el uso intensivo y las asignaciones de memoria intensas. La configuración predeterminada puede ser un poco demasiado baja, especialmente en sistemas con mucha memoria, y se debe considerar aumentarla con cuidado. Hemos visto que la memoria reservada por este ajuste evita que la caché del sistema operativo use toda la memoria y también evita que algunas operaciones malloc usen toda la memoria.
