Tengo un Ubuntu 16.04 Backup Server con 8x10TB HDD a través de un plano posterior SATA 3.0. Los 8 discos duros se ensamblan en un RAID6, se está utilizando un sistema de archivos EXT4. Este sistema de archivos almacena una gran cantidad de archivos pequeños con muchas operaciones SEEK pero bajo rendimiento de E / S. De hecho, hay muchos archivos pequeños de diferentes servidores que se toman instantáneas a través de rsnapshot todos los días (múltiples INODES directos a los mismos archivos. Tengo un rendimiento muy pobre ya que el sistema de archivos (60 TB netos) superó el 50% de uso. En este momento, el el uso es al 75% y un

du -sch /backup-root/

Tarda varios días (!). La máquina tiene 8 núcleos y 16G de RAM. La memoria RAM es totalmente utilizada por la caché del sistema de archivos del sistema operativo, 7 de 8 núcleos siempre inactivos debido a IOWAIT.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Me falta experiencia con este tipo de uso del sistema de archivos. ¿Qué opciones tengo para ajustar esto? ¿Qué sistema de archivos funcionaría mejor con este escenario? ¿Hay alguna opción para involucrar RAM para otras opciones de almacenamiento en caché que no sea el sistema operativo integrado?

¿Cómo maneja grandes cantidades de archivos pequeños en ensamblajes RAID grandes?

Gracias Sebastián

Tengo una configuración similar (aunque más pequeña), con discos de 12x 2TB en una matriz RAID6, utilizada para el mismo propósito ( rsnapshotservidor de respaldo).

Primero, es perfectamente normal du -hstomarse tanto tiempo en un sistema de archivos tan grande y usado. Además du, tiene en cuenta los enlaces duros, que causan una carga de CPU considerable y explosiva además de la carga de E / S obvia.

Su lentitud se debe a que los metadatos del sistema de archivos se encuentran en bloques muy distantes (en términos de LBA), lo que provoca muchas búsquedas. Como un disco normal de 7.2K RPM proporciona aproximadamente ~ 100 IOPS, puede ver cómo se necesitan horas, si no días, para cargar todos los metadatos.

Algo que puede intentar (no destructivamente) mejorar la situación:

• asegúrese de no tener que mlocate/slocateindexar su /backup-root/(puede usar el recurso prunefs para evitar eso), o la eliminación de la memoria caché de metadatos afectará gravemente su tiempo de copia de seguridad;
• por la misma razón, evitar correr duen /backup-root/. Si es necesario, ejecute dusolo en la subcarpeta específica interesada;
• menor vfs_cache_pressuredel valor predeterminado (100) a uno más conservador (10 o 20). Esto le indicará al núcleo que prefiera el almacenamiento en caché de metadatos, en lugar del almacenamiento en caché de datos; esto debería, a su vez, acelerar la rsnapshot/rsyncfase de descubrimiento;
• puede intentar agregar un dispositivo de almacenamiento en caché de metadatos de escritura, por ejemplo a través de lvmcache o bcache . Este dispositivo de metadatos obviamente debería ser un SSD;
• aumenta tu RAM disponible.
• mientras usa ext4, tenga en cuenta los problemas de asignación de inodo (lea aquí para ver un ejemplo). Esto no está directamente relacionado con el rendimiento, pero es un factor importante cuando se tienen tantos archivos en un sistema de archivos basado en ext.

Puede intentar otras cosas, pero estas son operaciones destructivas:

• use XFS con ambos -ftypey -finobtconjunto de opciones;
• use ZFS en Linux (ZoL) con ARC comprimido y primarycache=metadataconfiguración (y, tal vez, un L2ARC para caché de solo lectura).

Este sistema de archivos almacena una gran cantidad de archivos pequeños con muchas operaciones SEEK pero bajo rendimiento de E / S.

🎉

Esto es algo que atrapa a mucha gente hoy en día. Por desgracia, los FSes convencionales no escalan bien aquí. Probablemente pueda darle algunos consejos cuando se trata de la configuración que ya tiene: EXT4 sobre RAID-6 en HDD :

1. Más vm.vfs_cache_pressureabajo, digamos a 1. Cambiaría el sesgo de almacenamiento en caché hacia la preservación de más metadatos (inodo, dentry) en lugar de datos en sí y debería tener un efecto positivo en la reducción del número de búsquedas
2. Agrega más RAM . Aunque puede parecer extraño para un servidor que no ejecuta ninguna aplicación piggy, recuerde: la única forma de reducir las búsquedas es mantener más metadatos en un almacenamiento más rápido, dado que solo tiene 16 GB, parece que debería ser relativamente fácil aumentar la cantidad de RAM
3. Como he dicho, EXT4 no es una buena opción para el caso de uso que tiene, pero aún así puede usar algunas de las funciones que presenta para aliviar el dolor:
   • el diario externo es compatible, por lo que puede intentar agregar SSD (mejor reflejado) y colocar el diario allí. Echa un vistazo a " ext4: advertencias de revistas externas "
   • Intente cambiar el modo de diario a "todos los datos que se registran en diario" montando condata=journal
4. Intente mover archivos fuera del alcance de FS único . Por ejemplo, si tiene LVM-2 aquí, puede crear volúmenes de menor tamaño y usarlos por un tiempo, luego, cuando se llene, cree otro y así sucesivamente.
   • Si no tiene LVM-2, puede intentar hacerlo con / dev / loop pero no es tan conveniente y probablemente sea menos eficiente

UPD : dado que resultó ser RAID-6 de software RAID de Linux (LSR), aquí va un elemento adicional:

5. LSR tiene sus propias opciones de ajuste que muchas personas parecen pasar por alto
   • Stripe cache , que se puede configurar al máximo: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Pero haga esto con cuidado (use un valor menor si es necesario) ya que el tamaño es múltiple y dependiendo del tamaño del fragmento que haya elegido, tomaría una cantidad diferente de RAM
   • Diario externo que también puede estar en esos SSD duplicados ( pero actualmente el dispositivo MD creado sin diario no se puede convertir para usar uno ).

- Eso es probablemente la mayor parte de lo que se puede mejorar sin rediseño desde cero.

Tengo un rendimiento muy bajo ya que el sistema de archivos (60 TB netos) superó el 50% de uso. Por el momento, el uso es del 75%.

Ese es un problema muy serio porque ese alto nivel de ocupación de espacio en disco solo empeora la fragmentación. Y más fragmentación significa más búsquedas. Ya no me pregunto por qué dio un rendimiento más o menos aceptable antes de alcanzar el 50%. Muchos manuales tienen recomendaciones claras para no permitir que los FS crezcan detrás del 75-80%.

RAID6 no le ayuda mucho en este caso, algo como ZFS podría permitir metadatos y acceso a directorios mucho más rápidos mientras mantiene velocidades casi iguales.

Unidades de bandas RAID-6, por lo tanto, todo IO va a todas las unidades. Eso es bastante ineficiente con muchos archivos pequeños. Sin embargo, este probablemente no sea tu problema principal, que es ...

Ext4 no es adecuado para grandes sistemas de archivos con millones de archivos. Utiliza XFS . Tengo sistemas de archivos XFS con un tamaño de hasta 1,2 PB y con hasta mil millones de archivos, no hay problema. Simplemente use XFS .

Gracias a todos los que respondieron a mi pregunta.

Así es como lo resolví:

En primer lugar, agregué la cantidad máxima de RAM a la placa. Desafortunadamente, la placa solo admite hasta 64 GB de RAM. Observé el comportamiento después de la expansión, y fue decepcionante. Aunque toda la RAM disponible se usó para IO Cache, el rendimiento de RSNAPSHOT-Backup no mejoró notablemente.

Así que tuve que tirar de la maza grande. Agregué dos discos NVME de 1TB y los ensamblé en un RAID 1. El RAID 6 que consta de 8x 10TB HDD se desarmó en un RAID 1 (que consiste en 2x 10TB HDD, ext4) y un RAID 5 (que consiste en 6x10TB HDD). El RAID 1 ahora contiene el sistema operativo y la copia de trabajo de los servidores (que se inician 4 veces al día en esta unidad).

El RAID5 ahora es un dispositivo respaldado por BCACHE, respaldado por el NVME-RAID 1 y formateado con ext4. Esta unidad contiene las copias RSNAPSHOT. Todas las noches, los archivos se transfieren del RAID1 al RAID5, lo que reduce a la mitad el rendimiento de E / S del RAID5 en comparación con el RAID6 anterior, que contenía las copias de trabajo Y las instantáneas de respaldo. Gracias a BCache, no literalmente todos los archivos se escriben en los Discos, pero todos los cambios en un Bloque se escriben una vez, incluso si contiene varios cambios de archivos individuales de cientos. Esto disminuyó aún más las IOps en los discos duros.

Finalmente, cambié mi configuración de RSnapshot. Anteriormente, había 31 instantáneas diarias y 18 instantáneas mensuales, lo que daba como resultado 49 generaciones de respaldo. Ahora, tengo el diseño clásico 7d / 4w / 12m / 1y, que reduce la cantidad de generaciones de copias de seguridad a 24.

Después de estos cambios (y con los 64 GB de RAM mencionados anteriormente), la duración de una instantánea se redujo de ~ 20 horas a 1,5 horas. Los dispositivos BCache tienen una tasa de aciertos de caché del 82% (después de 6 semanas de funcionamiento normal).

Misión cumplida. Gracias a todos por sus pensamientos y comentarios.