Que es VM.min_free_kbytes y cómo sintonizarlo?
Cómo VM.Min_free_kbytes funciona
El sistema puede necesitar las asignaciones de memoria para garantizar el funcionamiento adecuado del sistema en sí. Si el núcleo permite que se asigne toda la memoria, podría tener dificultades al necesitar la memoria para operaciones regulares para mantener el sistema operativo funcionando sin problemas. Por eso el núcleo proporciona la VM sintonizable.min_free_kbytes. El sintonizable obligará al administrador de memoria del kernel a mantener al menos x cantidad de memoria libre. Aquí está la definición oficial de la documentación del núcleo de Linux: “Esto se usa para obligar a la VM de Linux a mantener un número mínimo de kilobytes gratis. La VM usa este número para calcular un valor de marca de agua [wark_min] para cada zona de LowMem en el sistema. Cada zona de LowMem obtiene una serie de páginas libres reservadas basadas proporcionalmente en su tamaño. Se necesita una cantidad mínima de memoria para satisfacer las asignaciones PF_MEMALLOC; Si establece esto en menos de 1024 kb, su sistema se romperá sutilmente y es propenso a un punto muerto bajo cargas altas. Establecer esto demasiado alto OOM su máquina al instante."
Validación de VM.Min_free_kbytes funciona
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. Use el comando gratuito a continuación para analizar el sistema:
# gratis -m
Mirando la utilidad de memoria gratuita arriba utilizando el indicador -m para imprimir los valores en MB. La memoria total es 3.5 a 3.75 GB de memoria. Se usan 121 MB de memoria, 3.3 GB de memoria es gratuita, el caché de buffer usa 251 MB. Y 3.3 GB de memoria están disponibles.
Ahora vamos a cambiar el valor de VM.min_free_kbytes y ver cuál es el impacto en la memoria del sistema. Haremos eco del nuevo valor al sistema de archivos Virtual PROC para cambiar el valor del parámetro del núcleo según lo siguiente:
# echo 1500000>/proc/sys/vm/min_free_kbytes
# SYSCTL VM.min_free_kbytes
Puedes ver que el parámetro se cambió a 1.5 GB aproximadamente y ha entrado en vigencia. Ahora usemos el gratis Comandar nuevamente para ver cualquier cambio reconocido por el sistema.
# gratis -m
La memoria libre y el caché del búfer no cambian por el comando, 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 Min Memoria libre.
Ahora creemos un archivo de datos de 2GB y luego veamos qué lectura hace ese archivo en el caché de búfer a los valores. Aquí está cómo crear un archivo de datos de 2 GB 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.Txt Count = 1000000
# para i en 'seq 1 70'; hacer eco $ i; gato /root /d1.txt >> /root /data_file; hecho
Lectemos el archivo e ignoremos el contenido leyendo y redirigiendo el archivo a /dev /null según a continuación:
# Cat data_file> /dev /null
Ok, lo que ha sucedido con la memoria de nuestro sistema con este conjunto de maniobras, verifíquelo ahora:
# gratis -m
Analizar los resultados anteriores. Todavía tenemos 1.8 GB de memoria libre, por lo que el núcleo ha protegido una gran parte de la memoria como reservada debido a nuestra configuración MIN_FREE_KBYTES. El caché del búfer ha usado 1691 MB, que es menor que el tamaño total de nuestro archivo de datos, que es 2.3 GB. Aparentemente todo archivo de datos No se pudo almacenar en caché debido a la falta de memoria disponible para usar para el caché del búfer. Podemos validar que todo el archivo no se almacena en caché, pero cronometramos los intentos repetidos de leer el archivo. Si se almacenara en caché, se necesitaría una fracción de segundo leer el archivo. Vamos a intentarlo.
# Time Cat data_file> /dev /null
# Time Cat data_file> /dev /null
La lectura del archivo tomó casi 20 segundos, lo que implica que casi con certeza no todo en caché.
Como validación final, reduzcamos la VM.min_free_kbytes para permitir que el caché de la página tenga más espacio para operar y podemos esperar ver que el caché funcione y el archivo se lee mucho más rápido.
# echo 67584>/proc/sys/vm/min_free_kbytes
# Time Cat data_file> /dev /null
# Time Cat data_file> /dev /null
Con la memoria adicional disponible para almacenar en caché el tiempo de lectura del archivo que se redujo de 20 segundos antes a .364 segundos con todo en caché.
Tengo curiosidad por hacer otro experimento. ¿Qué sucede con las llamadas de Malloc para asignar la memoria de un programa C frente a esta VM realmente alta?.ajuste de min_free_kbytes. ¿Fallará el malloc?? ¿Morirá el sistema?? Primero reinicie el VM.Min_free_kbytes Configuración al valor realmente alto para reanudar nuestros experimentos:
# echo 1500000>/proc/sys/vm/min_free_kbytes
Veamos nuevamente nuestra memoria gratuita:
Teóricamente tenemos 1.9 GB gratis y 515 MB disponible. Usemos un programa de prueba de estrés llamado Stress-NG para usar algo de memoria y ver dónde fallamos. Usaremos el probador de VM e intentaremos asignar 1 GB de memoria. Ya que solo tenemos 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 60s
Stress-NG: Información: [17537] despachando cerdos: 1 VM
Stress-NG: Información: [17537] Al Asignación de caché: Tamaño de caché predeterminado: 46080k
Stress-NG: Información: [17537] Ejecución exitosa completada en 60.09s (1 min, 0.09 secs)
# stress-ng --vm 2 --vm-bytes 1G-TimeOut 60s
# stress-ng --vm 3 --vm-bytes 1G-TimeOut 60s
Vamos a intentarlo nuevamente con más trabajadores, podemos probar 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 estresores de memoria con 1GB cada uno en un 3.Sistema de 75 GB.
# echo 67584>/proc/sys/vm/min_free_kbytes
# stress-ng --vm 3 --vm-bytes 1G-TimeOut 60s
Esta vez se ejecutó con éxito sin error, 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 VM.min_free_kbytes El valor 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 sacudido, tendería a aumentarlo un poco a 128 MB para permitir una memoria libre más reservada, sin embargo, para el uso promedio, el valor predeterminado parece ser sensible lo suficientemente sensato. La documentación oficial advierte sobre hacer que el valor sea demasiado alto. Configurarlo 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 reiniciados
Para garantizar que la configuración pueda sobrevivir a los reiniciados y no se restablezca a los valores predeterminados al reiniciarse, asegúrese de hacer que la configuración SYSCTL sea persistente al poner el nuevo valor deseado en el /etc /sysctl.archivo conf.
Conclusión
Hemos visto que la VM.Min_free_kbytes Linux Kernel sintonizable se puede modificar y puede reservar la memoria en el sistema para garantizar que el sistema sea más estable, especialmente durante el uso pesado y las asignaciones de memoria pesada. La configuración predeterminada puede ser un poco demasiado baja, especialmente en los sistemas de memoria alta y debe considerarse para aumentar cuidadosamente. Hemos visto que la memoria reservada por este sintonizable evita que el caché del sistema operativo use toda la memoria y también evita que algunas operaciones de malloc usen toda la memoria también.