¿Por qué mis sistemas de archivos XFS de repente consumen más espacio y están llenos de archivos dispersos?

62

He ejecutado sistemas de archivos XFS como particiones de datos / crecimiento durante casi 10 años en varios servidores Linux.

He notado un fenómeno extraño con los recientes servidores CentOS / RHEL que ejecutan la versión 6.2+.

El uso estable del sistema de archivos se volvió muy variable después del cambio a la revisión más reciente del sistema operativo de EL6.0 y EL6.1. Los sistemas instalados inicialmente con EL6.2 + exhiben el mismo comportamiento; mostrando cambios bruscos en la utilización del disco en las particiones XFS (consulte la línea azul en el gráfico a continuación).

Antes y después de. La actualización de 6.1 a 6.2 ocurrió el sábado. gráfico xfs

Gráfico de uso del disco del último trimestre del mismo sistema, que muestra las fluctuaciones de la última semana. ingrese la descripción de la imagen aquí

Comencé a verificar los sistemas de archivos para archivos grandes y procesos fuera de control (¿archivos de registro, tal vez?). Descubrí que mis archivos más grandes informaban valores diferentes de duy ls. Correr ducon y sin el --apparent-sizeinterruptor ilustra la diferencia.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Una comprobación rápida con la utilidad ncdu en todo el sistema de archivos arrojó:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

¡El sistema de archivos está lleno de archivos dispersos , con casi 70 GB de espacio perdido en comparación con la versión anterior del sistema operativo / kernel!

Revisé el Bugzilla de Red Hat y cambié los registros para ver si había informes del mismo comportamiento o nuevos anuncios con respecto a XFS.

Nada

Pasé de la versión del kernel 2.6.32-131.17.1.el6 a 2.6.32-220.23.1.el6 durante la actualización; sin cambios en el número de versión menor.

Verifiqué la fragmentación de archivos con la filefragherramienta. Algunos de los archivos más grandes en la partición XFS tenían miles de extensiones. La ejecución de la desfragmentación en línea xfs_fsr -vdurante un período lento de actividad ayudó a reducir el uso del disco temporalmente (consulte el miércoles en el primer gráfico anterior). Sin embargo, el uso se disparó tan pronto como se reanudó la actividad del sistema.

¿Que está sucediendo aquí?

ewwhite
fuente
2
Mmm ... Piazza ....
Tom O'Connor

Respuestas:

76

Rastreé este problema hasta una discusión sobre un compromiso con el árbol de origen XFS desde diciembre de 2010. El parche se introdujo en el Kernel 2.6.38 (y, obviamente, más tarde se introdujo en algunos núcleos de distribución Linux populares).

Las fluctuaciones observadas en el uso del disco son el resultado de una nueva característica; Preasignación dinámica especulativa de XFS EOF .

Este es un movimiento para reducir la fragmentación de archivos durante la transmisión de escrituras al asignar espacio especulativo a medida que aumenta el tamaño de los archivos. La cantidad de espacio preasignado por archivo es dinámica y es principalmente una función del espacio libre disponible en el sistema de archivos (para evitar quedarse sin espacio por completo).

Sigue este horario:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Esta es una adición interesante al sistema de archivos, ya que puede ayudar con algunos de los archivos masivamente fragmentados con los que trato.

El espacio adicional se puede recuperar temporalmente liberando el caché de página, las dentries e inodos con:

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

La característica se puede deshabilitar por completo definiendo un allocsizevalor durante el montaje del sistema de archivos. El valor predeterminado para XFS es allocsize=64k.

El impacto de este cambio probablemente lo sentirán los sistemas de monitoreo / umbralización (que es como lo capté), pero también ha afectado los sistemas de bases de datos y podría causar resultados impredecibles o no deseados para máquinas virtuales y arreglos de almacenamiento de aprovisionamiento delgado (usarán más espacio del que esperas).

En general, me pilló desprevenido porque no hubo un anuncio claro del cambio en el sistema de archivos a nivel de distribución o incluso en el monitoreo de la lista de correo XFS .


Editar : el
rendimiento en los volúmenes XFS con esta característica se mejora drásticamente Veo una fragmentación <1% constante en volúmenes que mostraban previamente hasta 50% de fragmentación. ¡El rendimiento de escritura ha aumentado a nivel mundial!

Estadísticas del mismo conjunto de datos, comparando XFS heredado con la versión en EL6.3.

Antiguo:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Nuevo:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%
ewwhite
fuente
44
Un millón de votos a favor y mi reino para ti
Joel E Salas
1
¡Gracias! Acabamos de actualizar Debian Squeeze a Ubuntu y nos preguntamos por qué du y ls mostraban valores tan diferentes para archivos grandes (por ejemplo, 50Mb frente a 64Mb)
Giles Thomas
1
@ewwhite ¿Desactivó esta función para recuperar el espacio? ¿O este artículo solo dice, oye, esta característica es lo que estaba causando la discrepancia en los tamaños informados? Parece "en sistemas de bases de datos o máquinas virtuales de aprovisionamiento delgado, considere desactivar esto", pero no estoy seguro de lo que decidió hacer, en última instancia.
JDS
2
@jds lo dejo encendido. Elimina la fragmentación y ha mejorado el rendimiento de mis aplicaciones.
ewwhite
3
Oh, maravilloso hallazgo. Esto estaba usando 750 GB en 35 GB de archivos. Después xfs_fsrde volver a bajar a unos 35 GB. Tendré que vigilar eso