Rendimiento de ZFS: ¿necesito mantener espacio libre en un grupo o en un sistema de archivos?

Sé que el rendimiento de ZFS depende en gran medida de la cantidad de espacio libre:

Mantenga el espacio de la agrupación por debajo del 80% de utilización para mantener el rendimiento de la agrupación. Actualmente, el rendimiento del grupo puede degradarse cuando un grupo está muy lleno y los sistemas de archivos se actualizan con frecuencia, como en un servidor de correo ocupado. Los grupos completos pueden causar una penalización de rendimiento, pero no otros problemas. [...] Tenga en cuenta que incluso con contenido estático en su mayoría en el rango de 95-96%, el rendimiento de escritura, lectura y recuperación podría verse afectado. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Ahora, supongamos que tengo un grupo de raidz2 de 10T que aloja un sistema de archivos ZFS volume. Ahora creo un sistema de archivos hijo volume/testy le doy una reserva de 5T.

Luego monte ambos sistemas de archivos por NFS en algún host y realizo algún trabajo. Entiendo que no puedo escribir en volumemás de 5T, porque los 5T restantes están reservados para volume/test.

Mi primera pregunta es, ¿cómo disminuirá el rendimiento si lleno mi volumepunto de montaje con ~ 5T? ¿Caerá, porque no hay espacio libre en ese sistema de archivos para copiar y escribir de ZFS y otras cosas meta? ¿O seguirá siendo el mismo, ya que ZFS puede usar el espacio libre dentro del espacio reservado para volume/test?

Ahora la segunda pregunta . ¿Hay alguna diferencia si cambio la configuración de la siguiente manera? volumeahora tiene dos sistemas de archivos volume/test1y volume/test2. Ambos reciben una reserva 3T cada uno (pero sin cuotas). Supongamos ahora, escribo 7T a test1. ¿El rendimiento para ambos sistemas de archivos será el mismo o será diferente para cada sistema de archivos? ¿Caerá o permanecerá igual?

¡Gracias!

Si. Necesita mantener espacio libre en su piscina. Es principalmente para acciones de copia en escritura e instantáneas. El rendimiento disminuye a aproximadamente el 85% de utilización. Puedes ir más alto, pero hay un impacto definitivo.

No te metas con las reservas. Especialmente con NFS. No es necesario. Tal vez para un zvol, pero no NFS.

Sin embargo, no veo la confusión. Si tiene 10T, no use más del 85%. Calcule sus acciones adecuadamente, utilizando cuotas para limitar su uso. O no use ninguna cuota y monitoree el uso general de su grupo .

La degradación del rendimiento se produce cuando su zpool está muy lleno o muy fragmentado. La razón de esto es el mecanismo de descubrimiento de bloque libre empleado con ZFS. Opuesto a otros sistemas de archivos como NTFS o ext3, no hay un mapa de bits de bloque que muestre qué bloques están ocupados y cuáles están libres. En cambio, ZFS divide su zvol en (generalmente 200) áreas más grandes llamadas "metaslabs" y almacena los árboles AVL ¹ de información de bloque libre (mapa espacial) en cada metaslab. El árbol AVL equilibrado permite una búsqueda eficiente de un bloque que se ajuste al tamaño de la solicitud.

Si bien este mecanismo se ha elegido por razones de escala, desafortunadamente también resultó ser un gran dolor cuando ocurre un alto nivel de fragmentación y / o utilización del espacio. Tan pronto como todos los metaslabs transporten una cantidad significativa de datos, obtienes una gran cantidad de áreas pequeñas de bloques libres en lugar de una pequeña cantidad de áreas grandes cuando el grupo está vacío. Si ZFS necesita asignar 2 MB de espacio, comienza a leer y evaluar todos los mapas espaciales de metaslabs para encontrar un bloque adecuado o una forma de dividir los 2 MB en bloques más pequeños. Por supuesto, esto lleva algo de tiempo. Lo que es peor es el hecho de que costará muchas operaciones de E / S ya que ZFS leería todos los mapas espaciales de los discos físicos . Para cualquiera de tus escritos.

La caída en el rendimiento puede ser significativa. Si le gustan las fotos bonitas, eche un vistazo a la publicación del blog en Delphix, que tiene algunos números sacados de un grupo zfs (demasiado simplificado pero válido). Estoy robando descaradamente uno de los gráficos: mire las líneas azul, roja, amarilla y verde en este gráfico que representan (respectivamente) los grupos con una capacidad del 10%, 50%, 75% y 93% dibujada contra el rendimiento de escritura en KB / s mientras se fragmenta con el tiempo:

Una solución rápida y sucia a esto ha sido tradicionalmente el modo de depuración de metaslab (solo emita echo metaslab_debug/W1 | mdb -kwen tiempo de ejecución para cambiar instantáneamente la configuración). En este caso, todos los mapas espaciales se mantendrían en la RAM del sistema operativo, eliminando el requisito de E / S excesivas y costosas en cada operación de escritura. En última instancia, esto también significa que necesita más memoria, especialmente para grandes grupos, por lo que es una especie de RAM para el comercio de caballos de almacenamiento. Su grupo de 10 TB probablemente le costará de 2 a 4 GB de memoria ² , pero podrá llevarlo al 95% de la utilización sin mucha molestia.

¹ es un poco más complicado, si estás interesado, mira la publicación de Bonwick en mapas espaciales para más detalles

² si necesita una forma de calcular un límite superior para la memoria, use zdb -mm <pool>para recuperar el número de segmentsuso actual en cada metaslab, divídalo por dos para modelar el peor de los casos (cada segmento ocupado iría seguido de uno libre ), multiplíquelo por el tamaño de registro para un nodo AVL (dos punteros de memoria y un valor, dada la naturaleza de 128 bits de zfs y el direccionamiento de 64 bits sumaría hasta 32 bytes, aunque la gente generalmente asume 64 bytes para algunos razón).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Referencia: el resumen básico está contenido en esta publicación de Markus Kovero en la lista de correo zfs-debate , aunque creo que cometió algunos errores en su cálculo que espero haber corregido en el mío.