Antes de cambiar parámetros XFS, es necesario entender por qué los parámetros XFS predeterminados están causando problemas de rendimiento. Esto implica entender lo que su aplicación está haciendo y la forma como está reaccionando a esas operaciones.
Los problemas de rendimiento observables que se pueden corregir o reducir mediante ajustes, suelen ser causados por la fragmentación de archivos o la contención de recursos en el sistema de archivos. Existen varias formas de solucionar estos problemas y en algunos casos la corrección del problemas requerirá modificar la aplicación en lugar de la configuración del sistema de archivos.
Si usted no ha pasado por el proceso anteriormente, se recomienda que contacte a su ingeniero de soporte local de Red Hat para obtener asistencia.
Optimización para una gran cantidad de archivos
XFS impone un límite arbitrario del número de archivos que puede guardar un sistema de archivos. En general, este límite es lo suficientemente alto que nunca será alcanzado. Si usted sabe con anterioridad que el límite predeterminado es insuficiente, puede aumentar el porcentaje del espacio del sistema de archivos permitidos por inodos con el comando mkfs.xfs. Si se da cuenta del límite de archivos después de crear el sistema de archivos (que suele indicarse mediante errores ENOSPC cuando se intente crear un archivo o directorio aunque el espacio libre esté disponible), puede ajustar el límite con el comando xfs_growfs.
Cómo optimizar un gran número de archivos en un directorio individual
El tamaño de bloque de directorio se fija para el archivo del sistema de archivos, y no puede cambiarse excepto durante el formato inicial con mkfs. El bloque de directorio mínimo es el tamaño de bloque del sistema de archivos, el cual se predetermina aMAX (4 KB, tamaño de bloque de archivos). En general, no hay razón para reducir el tamaño de bloque de directorio.
Puesto que la estructura de directorio se basa en árbol-b, el cambio de bloque afecta la cantidad de información del directorio que puede recuperarse o modificarse por E/S física. Entre más grande sea el directorio, más operación de cada E/S se requerirá en un tamaño de bloque determinado.
Sin embargo, al usar un tamaño más grande de bloque de directorio, se consume más CPU por cada operación de modificación en comparación con la misma operación en un sistema de archivos de tamaño de bloque de directorio más pequeño. Es decir que para directorios pequeños, los bloques de directorios grandes se traducirán en modificaciones más bajas de rendimiento. Cuando el directorio alcanza un tamaño en el que la E/S es el factor limitante de rendimiento, los bloques de directorio producen mejor rendimiento.
La configuración predeterminada de un bloque de sistema de archivos de 4 KB y un directorio de bloque de directorio de 4 KB es mejor para directorios hasta de 1-2 millón de entradas con una longitud de nombre de 20-40 bytes por entrada. Si su sistema de archivos requiere más entradas, los tamaños superiores de bloque de directorio tienden a rendir mejor - un bloque de 16 KB es mejor que un sistema de archivos de con 1-10 millones de entradas de directorio, y un tamaño de bloque de 64 KB es mejor para sistemas de archivos con más de 10 millones de entradas de directorio.
Si la carga de trabajo usa búsquedas de directorios aleatorios más que modificaciones (es decir, las lecturas de directorios son más comunes o importantes que las escrituras de directorio), entonces los umbrales anteriores para aumentar el tamaño de bloque son aproximadamente un orden de magnitud inferior.
Optimización para concurrencia
A diferencia de otros sistemas de archivos, XFS puede realizar al mismo tiempo varios tipos de operaciones de asignación o desasignación, siempre y cuando las operaciones se presenten en objetos no compartidos. La operaciones de asignación o desasignación de extensiones pueden presentarse de manera concurrente, siempre y cuando las operaciones concurrentes se presenten en diferentes grupos de asignación. Igualmente, los inodos de asignación o desasignación pueden ocurrir al mismo tiempo, siempre y cuando las operaciones simultáneas afecten diferentes grupos de asignación.
La cantidad de grupos de asignación es importante cuando se utilizan máquinas con alto conteo de CPU y aplicaciones multihilos que intentan realizar operaciones simultáneas. Si hay solo cuatro grupos de asignación, entonces las operaciones de metadatos sostenidos y paralelos únicamente escalarán hasta cuatro CPU (límite de concurrencia provisto por el sistema). Para sistemas de archivos pequeños, asegúrese de que el número de grupos de asignación esté soportado por la concurrencia provista por el sistema. Para sistemas de archivos grandes (decenas de TB y superiores) las opciones de formato predeterminado suelen crear suficientes grupos de asignación para evitar limitación de concurrencia.
Las aplicaciones deben tener en cuenta los puntos de contención para usar el paralelismo inherente en la estructura del sistema de archivos XFS. No es posible modificar de forma concurrente un directorio, por lo tanto las aplicaciones que crean y retiran grandes cantidades de archivos deben evitar almacenar todos los archivos en un solo directorio. Cada directorio creado es colocado en un grupo de asignación diferente, de esta manera los archivos con técnicas de dispersión en múltiples subdirectorios proporcionan un patrón de almacenamiento más escalable en comparación con el uso de un directorio individual grande.
Optimización para aplicaciones que utilizan atributos extendidos
XFS puede almacenar directamente atributos en el inodo si hay espacio disponible en el inodo. Si el atributo se ajusta dentro del inodo, entonces puede ser recuperado y modificado sin requerir E/S adicional para recuperar bloques de atributos independientes. La diferencia de rendimiento entre los atributos en-línea y fuera de línea puede fácilmente ser una orden de magnitud más lenta para atributos fuera de línea.
Para el tamaño predeterminado de inodo de 256 bytes, hay disponibles 100 bytes de espacio de atributo aproximadamente, dependiendo del número de punteros de extensión de datos también almacenados en el inodo. El tamaño de inodo predeterminado es realmente útil para almacenar un número escaso de pequeños atributos.
El aumento del tamaño del inodo en tiempo mkfs puede también incrementar la cantidad de espacio disponible para atributos de almacenamiento en línea. Un inodo de 512 bytes aumenta el espacio disponible para atributos a350 aproximadamente; un inodo de 2 KB tiene 1900 bytes disponibles aproximadamente.
Sin embargo, existe un límite de tamaño de los atributos individuales que pueden almacenarse en línea -un límite máximo de 254 bytes tanto para el nombre del atributo como para el valor (es decir, un atributo con una longitud de nombre de 254 bytes estará en línea). Si se excede de estos tamaños límites obligará a los atributos a estar fuera de línea incluso si han tenido suficiente espacio para almacenar todos los atributos en el inodo.
Optimización para modificaciones de metadatos sostenidos
El tamaño de registro es el factor principal para determinar el nivel alcanzable de modificación de metadatos sostenidos. El dispositivo de registro es circular, por lo tanto antes de la cola pueden sobrescribirse todas las modificaciones en el registro en disco. Esto puede implicar una cantidad significativa de búsqueda para restaurar todos los datos sucios de metadatos. La configuración predeterminada escala el tamaño de registro en relación con el tamaño de sistema en general, por lo tanto en la mayoría de los casos el tamaño de registro no requerirá ajuste.
Un dispositivo pequeño de registro se traduce en escritura diferida - el registro empujará constantemente su cola para liberar el espacio y por lo tanto los metadatos que suelen ser modificados se escribirán en disco, retrasando así las operaciones.
El aumento del tamaño del registro aumenta el periodo de tiempo entre los eventos de envío de cola. Lo cual permite la mejor agregación de metadatos sucios, y a su vez, produce mejores patrones de retro-escritura de metadatos y menos retro-escritura de metadatos modificados con frecuencia. La desventaja es que los registros más grandes requieren más memoria para rastrear todos los cambios importantes en memoria.
Si usted tiene una máquina con una memoria limitada, entonces los registros grandes no son benéficos, ya que las limitaciones de memoria harán que los metadatos se restauren mucho antes que los beneficios de un registro grande pueda realizarse. En estos casos, los registros más pequeños proveerán mejor rendimiento que los grandes, puesto que los metadatos del registro que le falta espacio es más eficiente que la retro-escritura controlada por el reclamo de memoria.
Siempre debe tratar de alinear el registro con la banda subyacente del dispositivo que contiene el sistema de archivos. mkfs lo hace de forma predeterminada para dispositivos MD y DM, pero debe especificarse para RAID de hardware. Al configurarlo correctamente se evita toda posibilidad de que registro de E/S cause E/S no alineada y posteriores operaciones de 'lectura-modificar-escritura' al escribir los cambios al disco.
La operación de registro puede mejorarse al modificar las opciones. El aumento de tamaño de búferes de registro en memoria (logbsize) aumenta la velocidad de los cambios que pueden escribirse al registro. El tamaño de registro predeterminado es MAX (32 KB, unidad de banda de registro), y el tamaño máximo es 256 KB. En general, un valor superior produce un rendimiento más rápido. Sin embargo, en cargas de trabajo pesadas de fsync, los búferes de registro pequeño pueden ser notablemente más rápidos que los búferes grandes con una alineación de unidad de banda grande.
La opción de montaje delaylog también mejora el rendimiento de modificaciones de metadatos sostenidos mediante la reducción del número de cambios al registro. Esto se produce al agregar cambios individuales en memoria antes de escribirlos al registro: en lugar de escribir los metadatos frecuentes cada vez se modifican, se escriben al registro de forma periódica . Esta opción aumenta el uso de memoria de rastreo de metadatos sucios y aumenta las operaciones de pérdida potenciales cuando se presenta una falla, pero puede mejorar la velocidad de modificación de metadatos y la escalabilidad mediante un orden de magnitud o más. El uso de esta opción no reduce la integridad de los datos o metadatos cuando fsync, fdatasync o sync sean utilizados para garantizar que los datos y metadatos sean escritos a disco.
