¿Por qué soltar cachés en Linux?

En nuestros servidores tenemos la costumbre de soltar cachés a medianoche.

sync; echo 3 > /proc/sys/vm/drop_caches

Cuando ejecuto el código, parece liberar mucha RAM, pero ¿realmente necesito hacerlo? ¿No es un desperdicio de RAM libre?

Estás 100% correcto. Es no una buena práctica para liberar la memoria RAM. Este es probablemente un ejemplo de administración del sistema de culto de carga.

Sí, borrar la memoria caché liberará RAM, pero hace que el núcleo busque archivos en el disco en lugar de en la memoria caché, lo que puede causar problemas de rendimiento.

Normalmente, el kernel borrará la memoria caché cuando se agote la RAM disponible. Con frecuencia escribe contenido sucio en el disco usando pdflush.

La razón para descartar cachés como esta es para comparar el rendimiento del disco, y es la única razón por la que existe.

Al ejecutar un punto de referencia intensivo de E / S, debe asegurarse de que las diversas configuraciones que intente realmente estén haciendo E / S de disco, por lo que Linux le permite colocar cachés en lugar de reiniciar por completo.

Para citar de la documentación :

Este archivo no es un medio para controlar el crecimiento de los diversos cachés del núcleo (inodes, dentries, pagecache, etc.). Estos objetos son recuperados automáticamente por el núcleo cuando se necesita memoria en otra parte del sistema.

El uso de este archivo puede causar problemas de rendimiento. Dado que descarta los objetos almacenados en caché, puede costar una cantidad significativa de E / S y CPU recrear los objetos caídos, especialmente si se usaban mucho. Debido a esto, no se recomienda su uso fuera de un entorno de prueba o depuración.

La idea básica aquí probablemente no sea tan mala (solo muy ingenua y engañosa): puede haber archivos en caché, a los que es muy poco probable que se acceda en el futuro cercano, por ejemplo, archivos de registro. Estos "carnero" ram, que luego tendrá que ser liberado cuando sea necesario por el sistema operativo de una u otra manera.

Dependiendo de su configuración de intercambio, patrón de acceso a archivos, patrón de asignación de memoria y muchas cosas más impredecibles, puede suceder que cuando no libere estos cachés, más tarde se vean obligados a reutilizarse, lo que lleva un poco más de tiempo que asignación de memoria del conjunto de memoria no utilizada. En el peor de los casos, la configuración de intercambio de Linux hará que se intercambie la memoria del programa, porque Linux piensa que es más probable que esos archivos se usen en un futuro próximo que la memoria del programa.

En mi entorno, Linux adivina bastante a menudo mal, y al comienzo de la mayoría de las bolsas de valores de Europa (alrededor de las 0900 hora local) los servidores comenzarán a hacer cosas que hacen solo una vez al día, necesitando intercambiar en la memoria que se intercambió previamente debido a la escritura los archivos de registro, comprimirlos, copiarlos, etc., estaban llenando el caché hasta el punto en que las cosas tenían que cambiarse.

¿Pero la colocación de cachés es la solución a este problema? Definitivamente no. Lo que sería la solución aquí es decirle a Linux lo que no sabe: que estos archivos probablemente ya no se usarán. Esto se puede hacer mediante la aplicación de escritura usando cosas como posix_fadvise()o usando una herramienta de línea cmd como vmtouch(que también se puede usar para examinar cosas y archivos de caché).

De esa forma, puede eliminar los datos que ya no se necesitan de las memorias caché y conservar las cosas que deben almacenarse en la memoria caché, porque cuando suelta todas las memorias caché, debe volver a leer muchas cosas del disco. Y eso en el peor momento posible: cuando es necesario; causando retrasos en su aplicación que son notables y a menudo inaceptables.

Lo que debe tener en su lugar es un sistema que monitoree sus patrones de uso de memoria (por ejemplo, si algo está cambiando) y luego analice en consecuencia y actúe en consecuencia. La solución podría ser desalojar algunos archivos grandes al final del día usando vtouch; también podría ser agregar más ram porque el uso máximo diario del servidor es solo eso.

He visto que los cachés de caída son útiles al iniciar un montón de máquinas virtuales. O cualquier otra cosa que use páginas grandes, como algunos servidores de bases de datos.

Las páginas grandes en Linux a menudo necesitan desfragmentar la RAM para encontrar 2 MB de RAM física contigua para colocar en una página. Liberar todo el caché de archivos hace que este proceso sea muy fácil.

Pero estoy de acuerdo con la mayoría de las otras respuestas en que no hay una buena razón general para dejar el caché de archivos todas las noches.

Es posible que esto se haya instituido como una forma de estabilizar el sistema cuando no había nadie con las habilidades o la experiencia para encontrar realmente el problema.

Liberando recursos

La eliminación de cachés esencialmente liberará algunos recursos, pero esto tiene el efecto secundario de hacer que el sistema realmente trabaje más para hacer lo que está tratando de hacer. Si el sistema está intercambiando (tratando de leer y escribir desde una partición de intercambio de disco más rápido de lo que realmente es capaz), soltar cachés periódicamente puede aliviar el síntoma , pero no hace nada para curar la causa .

¿Qué es comer memoria?

Debe determinar qué está causando un gran consumo de memoria que hace que la eliminación de cachés parezca funcionar. Esto puede deberse a cualquier cantidad de procesos de servidor mal configurados o simplemente mal utilizados. Por ejemplo, en un servidor presencié la utilización máxima de la memoria cuando un sitio web de Magento alcanzó un cierto número de visitantes en un intervalo de 15 minutos. Esto terminó siendo causado por la configuración de Apache para permitir que se ejecuten demasiados procesos simultáneamente. Demasiados procesos, usando mucha memoria (Magento es una bestia a veces) = intercambio.

Línea de fondo

No solo asuma que es algo necesario. Sea proactivo en descubrir por qué está allí, tenga las agallas para deshabilitarlo si otros sugieren que está mal, y observe el sistema: aprenda cuál es el verdadero problema y corríjalo.

Linux / m68k en realidad tiene un error de kernel que hace que kswapd se vuelva loco y consuma el 100% de la CPU (50% si hay alguna otra tarea vinculada a la CPU, como un autoconstructor de paquetes binarios Debian - vulgo buildd - que ya se está ejecutando), que puede (la mayoría del tiempo; no siempre) se mitigue ejecutando este comando en particular cada pocas horas.

Dicho esto ... lo más probable es que su servidor no sea un sistema m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

En este caso, la persona que puso las líneas siguió algunos consejos cuestionables o, en el mejor de los casos, desactualizados, o tuvo la idea de cómo se debe usar la RAM de manera incorrecta (el pensamiento moderno de hecho dice "RAM libre se desperdicia RAM" y sugiere almacenamiento en caché) , o "descubrió" que esto "soluciona" [sic!] otro problema en otro lugar (y era demasiado vago para buscar una solución adecuada).

Una razón podría ser que el sitio está ejecutando algún tipo de monitoreo, que verifica la cantidad de memoria RAM gratuita y envía una advertencia a los administradores cuando la memoria RAM gratuita cae por debajo de un cierto porcentaje. Si esa herramienta de monitoreo es lo suficientemente tonta como para no incluir la memoria caché en el cálculo de ram libre, puede enviar advertencias falsas; vaciar regularmente el caché podría suprimir estas advertencias y, al mismo tiempo, permitir que la herramienta se dé cuenta cuando el "ram" real se agote.

Por supuesto, en este tipo de situación, la solución real es modificar la herramienta de monitoreo para incluir la memoria caché en el cálculo de ram libre; limpiar el caché es solo una solución alternativa, y también una mala, porque el caché se rellenará rápidamente cuando los procesos accedan al disco.

Entonces, incluso si mi suposición es cierta, la limpieza de caché no es algo que tenga sentido, es más bien una solución alternativa por alguien que no es lo suficientemente competente como para solucionar el problema principal.

Puedo pensar en una razón plausible para hacer esto en un trabajo nocturno de cron.

En un sistema grande, puede ser útil soltar cachés periódicamente para que pueda eliminar la fragmentación de la memoria.

El soporte de página grande transparente del núcleo hace un barrido periódico de memoria para unir páginas pequeñas en páginas grandes. En condiciones degeneradas, esto puede provocar pausas del sistema de uno o dos minutos (mi experiencia con esto fue en RHEL6; espero que haya mejorado). Dejar caer cachés puede permitir que la barredora de páginas grandes tenga algo de espacio para trabajar.

Podría argumentar que esta es una buena razón para deshabilitar las enormes páginas transparentes; OTOH puede creer que vale la pena tener la mejora general del rendimiento de las grandes páginas transparentes y pagar el precio de perder sus cachés una vez al día.

He pensado en otra razón por la que querrías hacerlo, aunque no en un trabajo cron. Justo antes de que un sistema de virtualización migre una VM a un nuevo hardware, sería un muy buen momento para esto. Menos contenido de memoria para copiar al nuevo host. Eventualmente, tendrá que leer desde el almacenamiento, por supuesto, pero probablemente tomaría esa compensación.

No sé si alguno de los software virt realmente hace esto.

Solo para agregar mis dos centavos: el sistema sabe muy bien que estas páginas de memoria son cachés, y caerán tanto como sea necesario cuando una aplicación solicite memoria.

Una configuración relevante es /proc/sys/vm/swappiness, que le dice al kernel durante las nuevas asignaciones de memoria que prefiera abandonar las memorias caché o intercambiar páginas de memoria asignadas "inactivas".

La pregunta es de 2014, pero como el problema existe hasta el día de hoy en algunos backends ocos 6.8 ocultos, aún puede ser útil para alguien.

https://github.com/zfsonlinux/zfs/issues/1548 describe un problema con zfs. Allí, no se libera espacio en disco para los archivos eliminados porque si se usa nfs encima de zfs, los inodos del archivo no se eliminan de la caché de inodos del núcleo.

Para citar el hilo del error, behlendorf, 6 de enero de 2015 escribió:

La especulación actual es que, por alguna razón, el servidor NFS mantiene una versión en caché del identificador de archivo. Hasta que el servidor NFS elimine este identificador de archivo, ZFS no puede desvincular este archivo. Algunas pruebas ligeras han demostrado que la caída de cachés en el servidor hará que esta referencia se caiga (como el identificador de archivo NFS) en cuyo punto el espacio se libera correctamente. La presión de la memoria también puede hacer que se caiga.

es decir, un eco nocturno 3> / proc / sys / vm / drop_caches es la solución más fácil para ese error si no desea tener un tiempo de inactividad para reestructurar sus zfs.

Entonces, tal vez no sea la administración del culto de carga, pero la razón fue una buena depuración.

Esto puede tener sentido en los sistemas NUMA (acceso de memoria no uniforme), donde, por lo general, cada CPU (socket) puede acceder a toda la memoria de forma transparente, pero se puede acceder a su propia memoria más rápido que la memoria de otro socket, en asociación con aplicaciones paralelas de HPC.

Muchas aplicaciones paralelas simples tienden a hacer E / S de archivo desde un solo proceso, dejando así una gran fracción de memoria en un solo nodo NUMA asignado a la caché de disco, mientras que en el otro nodo NUMA la memoria puede estar mayormente libre. En estas situaciones, dado que el proceso de recuperación de caché en el kernel de Linux, que yo sepa, todavía no es compatible con NUMA, los procesos que se ejecutan en el nodo NUMA que tiene memoria asignada a la caché están obligados a asignar memoria en el otro nodo NUMA, siempre que haya RAM libre en el otro nodo, matando así las actuaciones.

Sin embargo, en un sistema HPC, sería más inteligente limpiar el caché antes de comenzar un nuevo trabajo de usuario, no en un momento específico con cron.

Para aplicaciones no paralelas, es poco probable que surja este problema.

Cuando la memoria caché de su página es bastante grande (mucho más grande que su uso de intercambio actual), y el intercambio y el intercambio ocurren por turnos, es cuando necesita colocar cachés. He visto casos en los que el uso de memoria aumenta en uno de mis servidores de bases de datos MariaDB que ejecutan Ubuntu 16.04LTS, y Linux simplemente eligió aumentar el uso de intercambio en lugar de eliminar los cachés de página no utilizados. Las grandes páginas transparentes ya están deshabilitadas en mi sistema porque TokuDB requiere que esté deshabilitado. De todos modos, tal vez no sea un error, pero Linux que sigue haciendo este comportamiento es bastante desconcertante para mí. Varias fuentes declararon que Linux eliminaría el caché de página cuando la aplicación lo solicitara:

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Pero la realidad no es tan simple. La solución alternativa es:

1. Ejecutar soltar caché periódicamente
2. Ejecute drop cache cuando sea necesario (supervise usando vmstat 1 para intercambiar actividades)
3. Aconseje a Linux que elimine ciertos archivos de la memoria caché (como los archivos de registro de Apache) utilizando una utilidad como dd o python-fadvise. Ver https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Ejemplo dd run:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Ejemplo python-fadvise:

pyadvise -d /var/log/apache2/access_log.1

Tengo una máquina de escritorio con 16 GB de RAM ejecutándose en el kernel PAE. Después de una o dos horas, el rendimiento del disco se degrada drásticamente hasta que pierdo los cachés, así que simplemente lo pongo en cron. No sé si esto es un problema con el núcleo PAE o si la implementación de la memoria caché es tan lenta si hay mucha memoria.