Ajuste de ZFS ARC: límites máximos, restricciones y qué medir

Por defecto, ZFS ocupará discretamente aproximadamente la mitad de la RAM del sistema para su caché de lectura y, en un servidor inadecuado, eso puede traducirse en actividad de swap, terminaciones por falta de memoria (OOM) o una base de datos compitiendo con el sistema de archivos por la memoria. El ajuste del ARC de ZFS consiste en decidir cuánta de esa RAM se le permite realmente conservar al ARC y a qué se renuncia para establecer el límite. Este artículo explica cómo utiliza ARC la memoria, qué hay que medir antes de tocar nada, los pocos parámetros que vale la pena modificar y unos puntos de partida sensatos para servidores de archivos, hipervisores, bases de datos y destinos de copias de seguridad. En cuanto a las instantáneas de ZFS, consulta nuestra guía sobre instantáneas de ZFS.

Mide el ARC antes de ajustar nada

No modifique ningún parámetro ajustable hasta que disponga de cifras de referencia correspondientes a un periodo de tráfico normal. Las instantáneas tomadas en periodos de poco tráfico le llevarán por el camino equivocado. Las copias de seguridad nocturnas, los informes semanales y los trabajos por lotes suelen ser los momentos en los que el comportamiento del ARC resulta más interesante, por lo que debe recopilar datos a lo largo de varios días.

Tres herramientas cubren la mayor parte de lo que necesitas:

• arcstat 1 ofrece una vista en tiempo real y desplazable de los contadores de aciertos y fallos, la actividad de demanda frente a la de precarga, y el tamaño actual del ARC. Úsala durante las pruebas de carga y las ventanas de copia de seguridad.
• arc_summary imprime una única instantánea: el tamaño y el objetivo del ARC, la distribución entre MFU y MRU, las proporciones de metadatos y los parámetros ajustables activos. Ejecuta arc_summary -s arc solo para la sección de ARC.
• Los contadores sin procesar se encuentran /proc/spl/kstat/zfs/arcstats en Linux y bajo el kstat.zfs.misc y vfs.zfs árboles de sysctl en FreeBSD. Es mejor extraerlos del sistema de monitorización en lugar de analizar la salida formateada.

Los contadores que conviene registrar antes de cualquier cambio:

Hay dos cosas en las que la gente suele equivocarse aquí. Hay que fijarse en la memoria disponible, no en la memoria libre; Linux muestra sin problemas un nivel bajo de RAM libre como estado estable y eso, por sí solo, no es un problema. La señal que importa es que la memoria disponible sea casi nula, combinada con una actividad de intercambio sostenida (en la guía básica de gestión de memoria de Linux se explica por qué). Y considera la tasa de aciertos como una tendencia, no como un objetivo. Una tasa de aciertos del 99 % en un equipo que está recurriendo al intercambio es un fallo de optimización, no un éxito.

Los cuatro parámetros ajustables de ARC que importan

La mayor parte del ajuste en producción se reduce a cuatro parámetros. Adapta el ajuste a la presión que hayas medido realmente en la línea de base. La actividad de intercambio apunta a zfs_arc_max. Recuperar la pérdida de clientes que sigue borrando una caché activa apunta a zfs_arc_min. Los recorridos lentos por los directorios apuntan al límite de metadatos.

Empieza con el cambio más pequeño que resuelva la presión que puedas observar. En zfs_arc_max, el límite máximo adecuado depende de la carga de trabajo (se trata en la siguiente sección). En zfs_arc_min, un límite mínimo del 25 % al 50 % de zfs_arc_max es un punto de partida razonable, si es que se necesita alguno. En cuanto a los metadatos, los valores predeterminados recientes de OpenZFS ya les asignan el 75 % de ARC a través de zfs_arc_meta_limit_percent, lo cual es generoso para la mayoría de las cargas de trabajo; solo modifícalo cuando las pérdidas de metadatos sean claramente visibles en arcstat.

Aplicación de cambios en Linux y FreeBSD

En Linux, prueba un cambio en tiempo de ejecución escribiendo en el archivo de parámetros de sysfs. No es necesario reiniciar:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Esto establece zfs_arc_max a 16 GiB de forma inmediata. Para que el cambio se mantenga tras un reinicio, añádelo a /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

En FreeBSD, los cambios en tiempo de ejecución utilizan sysctl:

sysctl vfs.zfs.arc_max=17179869184

Para que el valor se mantenga en /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Cambia un parámetro cada vez, en pequeños incrementos de alrededor del 10 % de la RAM total. Observa la ventana de problemas. Mantén el cambio solo si el espacio de intercambio se mantiene en cero y la latencia es estable. Haz que el cambio sea permanente solo después de que la prueba en tiempo de ejecución haya dado resultado satisfactorio.

Ajuste del ARC según la carga de trabajo

La RAM total no es el punto de partida adecuado. El dimensionamiento de la ARC debe ajustarse a la combinación de cargas de trabajo del equipo.

Un host de máquinas virtuales necesita compartir memoria con sus invitados, por lo que un límite del 30 % al 40 % es un valor predeterminado seguro y el 50 % ya resulta demasiado alto en la mayoría de las configuraciones. Las bases de datos como PostgreSQL y MySQL gestionan sus propias cachés de búfer, por lo que primero se reserva memoria para el motor y se deja que ARC utilice lo que queda. Los destinos de copia de seguridad se benefician de primarycache=metadata , ya que los datos que se leen rara vez se vuelven a necesitar, y no es deseable que una copia de seguridad nocturna recorra todo el conjunto y vacíe el resto de la caché a medida que avanza. En todas las cargas de trabajo, la actividad de intercambio mientras ARC está fijado en zfs_arc_max significa que el límite es demasiado alto; esa regla no cambia.

Diagnosticar problemas y saber cuándo parar

Un ARC de tamaño insuficiente se manifiesta en un elevado número de IOPS de lectura, bajas tasas de aciertos en la demanda y una navegación lenta por los directorios, mientras que el sistema aún dispone de RAM libre. Un ARC de tamaño excesivo es menos evidente. La tasa de aciertos parece correcta, pero el servidor empieza a realizar intercambio de memoria, los promedios de carga suben, los procesos se bloquean en D estado mientras el kernel recupera páginas del ARC bajo demanda y, en el peor de los casos, el «OOM killer» empieza a elegir víctimas. La caché parece estar en buen estado, pero el servidor funciona muy mal.

La presión de metadatos se manifiesta cuando demand_metadata_bytes se sitúa muy por encima de demand_data_bytes en arc_summary. Es entonces cuando los metadatos compiten con los datos por el espacio, y conviene aumentar el límite porcentual de metadatos.

Compara lo que ves con el primer ajuste que debes comprobar:

L2ARC no es gratuito. El índice de las entradas de L2ARC reside en el ARC primario, y si esa sobrecarga supera aproximadamente un tercio de la capacidad total del ARC, la caché secundaria hace más daño que bien. Recurre a L2ARC solo cuando el conjunto de trabajo sea mayor que la RAM, pero aún quepa en un dispositivo NVMe rápido, y únicamente cuando la tasa de aciertos de la ARC primaria ya sea satisfactoria.

El momento adecuado para dejar de ajustar la configuración es cuando la latencia se mantiene estable, el intercambio se mantiene en cero durante el mismo periodo de máxima actividad que causó el problema original, y los cambios adicionales ya no mejoran nada. Una alta tasa de aciertos no significa nada si el servidor está realizando intercambio. Pasado ese punto, deja de ajustar la configuración y revísala solo si el mismo problema vuelve a aparecer con la misma carga de trabajo.

Si necesitas un servidor con margen de RAM suficiente para ejecutar ZFS correctamente sin tener que competir por la memoria con tus máquinas virtuales o bases de datos (merece la pena leer primero «¿Cuánta RAM necesitas realmente?»), echa un vistazo a los servidores dedicados de FDC.