J'ai un serveur de sauvegarde Ubuntu 16.04 avec un disque dur de 8 x 10 To via un fond de panier SATA 3.0. Les 8 disques durs sont assemblés en RAID6, un système de fichiers EXT4 est en cours d'utilisation. Ce système de fichiers stocke une énorme quantité de petits fichiers avec de très nombreuses opérations SEEK mais un faible débit d'E / S. En fait, il existe de nombreux petits fichiers provenant de serveurs différents qui sont instantanés via rsnapshot chaque jour (plusieurs INODES directement vers les mêmes fichiers. J'ai de très mauvaises performances car le système de fichiers (60 To net) a dépassé 50% d'utilisation. À l'heure actuelle, le l'utilisation est à 75% et un

du -sch /backup-root/

prend plusieurs jours (!). La machine a 8 cœurs et 16 Go de RAM. La RAM est totalement utilisée par le cache du système de fichiers du système d'exploitation, 7 des 8 cœurs étant toujours inactifs à cause d'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

Je manque d'expérience avec ce type d'utilisation du système de fichiers. Quelles options dois-je régler cela. Quel système de fichiers fonctionnerait mieux avec ce scénario? Existe-t-il des options pour impliquer la RAM pour d'autres options de mise en cache que celle intégrée au système d'exploitation?

Comment gérez-vous de très grandes quantités de petits fichiers sur de grands assemblages RAID?

Merci, Sebastian

J'ai une configuration similaire (quoique plus petite), avec 12 disques de 2 To dans une matrice RAID6, utilisée dans le même but ( rsnapshotserveur de sauvegarde).

Tout d'abord, il est parfaitement normal du -hsde prendre autant de temps sur un système de fichiers aussi volumineux et utilisé. En outre dureprésente, qui provoquent des liens physiques charge CPU considérable et en plus bursty la charge évidente IO.

Votre lenteur est due au fait que les métadonnées du système de fichiers sont situées dans des blocs très éloignés (en termes LBA), provoquant de nombreuses recherches. Comme un disque RPM 7,2 K normal fournit environ 100 IOPS, vous pouvez voir combien d'heures, sinon des jours, sont nécessaires pour charger toutes les métadonnées.

Quelque chose que vous pouvez essayer d'améliorer (de manière non destructive) la situation:

• assurez-vous de ne pas avoir d' mlocate/slocateindexation de votre /backup-root/(vous pouvez utiliser la fonction prunefs pour éviter cela), sinon la mise en cache du cache de métadonnées réduira considérablement votre temps de sauvegarde;
• pour la même raison, éviter de faire fonctionner dusur /backup-root/. Si nécessaire, exécutez duuniquement sur le sous-dossier spécifique intéressé;
• inférieure vfs_cache_pressurede la valeur par défaut (100) à une valeur plus conservatrice (10 ou 20). Cela indiquera au noyau de préférer la mise en cache des métadonnées, plutôt que la mise en cache des données; cela devrait, à son tour, accélérer la rsnapshot/rsyncphase de découverte;
• vous pouvez essayer d'ajouter un périphérique de mise en cache des métadonnées par écrit, par exemple via lvmcache ou bcache . Ce périphérique de métadonnées devrait évidemment être un SSD;
• augmentez votre RAM disponible.
• lorsque vous utilisez ext4, soyez conscient des problèmes d'allocation d'inode (lisez ici pour un exemple). Ce n'est pas directement lié aux performances, mais c'est un facteur important lorsque vous avez autant de fichiers sur un système de fichiers basé sur ext.

Vous pouvez essayer d'autres choses, mais ce sont des opérations destructrices:

• utiliser XFS avec les deux -ftypeet le -finobtjeu d'options;
• utilisez ZFS sur Linux (ZoL) avec ARC et primarycache=metadataparamètre compressés (et, peut-être, un L2ARC pour le cache en lecture seule).

Ce système de fichiers stocke une énorme quantité de petits fichiers avec de très nombreuses opérations SEEK mais un faible débit d'E / S.

🎉

C'est une chose qui attire beaucoup de gens de nos jours. Hélas, les FS conventionnels ne se mettent pas bien à l'échelle ici. Je peux probablement vous donner quelques conseils en ce qui concerne la configuration que vous avez déjà: EXT4 sur RAID-6 sur les disques durs :

1. Plus vm.vfs_cache_pressurebas, disons à 1. Cela changerait le biais de mise en cache vers la préservation de plus de métadonnées (inode, dentry) au lieu des données elles-mêmes et cela devrait avoir un effet positif sur la réduction du nombre de recherches
2. Ajoutez plus de RAM . Bien que cela puisse paraître étrange pour un serveur qui n'exécute aucune application piggy, rappelez-vous: la seule façon de réduire les recherches est de conserver plus de métadonnées dans un stockage plus rapide, étant donné que vous n'avez que 16 Go, il semble qu'il devrait être relativement facile de augmenter la quantité de RAM
3. Comme je l'ai dit, l'EXT4 n'est pas un bon choix pour le cas d'utilisation que vous avez, mais vous pouvez toujours utiliser certaines des fonctionnalités qu'il soulage pour soulager la douleur:
   • le journal externe est pris en charge afin que vous puissiez essayer d'ajouter un SSD (mieux mis en miroir) et d'y placer le journal. Consultez " ext4: mises en garde de journaux externes "
   • Essayez de basculer le mode journal sur le montage "toutes les données sont journalisées" avecdata=journal
4. Essayez de déplacer des fichiers en dehors de la portée FS unique . Par exemple, si vous avez LVM-2 ici, vous pouvez créer des volumes de taille inférieure et les utiliser pendant un certain temps, puis quand il est plein, créez-en un autre et ainsi de suite.
   • Si vous n'avez pas LVM-2, vous pouvez essayer de le faire avec / dev / loop mais ce n'est pas si pratique et probablement moins performant

UPD. : comme il s'est avéré être un RAID logiciel Linux (LSR) RAID-6, voici un élément supplémentaire:

5. LSR a ses propres options de réglage que beaucoup de gens semblent ignorer
   • Cache de bande , qui peut être réglé ainsi au maximum: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Mais faites-le avec soin (utilisez moins de valeur si nécessaire) car la taille est multiple de la taille du bloc et en fonction de la taille du bloc que vous avez choisie, il faudrait une quantité différente de RAM
   • Journal externe qui peut également être sur ces SSD en miroir ( mais le périphérique MD créé actuellement sans journal ne peut pas être converti pour en utiliser un ).

- C'est probablement la majeure partie de ce qui peut être amélioré sans une nouvelle conception.

J'ai une très mauvaise performance car le système de fichiers (60 To net) a dépassé 50% d'utilisation. À l'heure actuelle, l'utilisation est à 75%

C'est un problème très grave car ce niveau d'occupation d'espace disque élevé ne fait qu'aggraver la fragmentation. Et plus de fragmentation signifie plus de recherches. Je ne me demande plus pourquoi il a donné des performances plus ou moins acceptables avant d'atteindre 50%. De nombreux manuels contiennent des recommandations claires pour ne pas permettre aux FS de se développer derrière 75 à 80%.

RAID6 ne vous aide pas beaucoup dans ce cas, quelque chose comme ZFS pourrait permettre un accès beaucoup plus rapide aux métadonnées et aux répertoires tout en maintenant des vitesses à peu près les mêmes.

Les disques à bandes RAID-6, donc toutes les E / S vont à tous les disques. C'est assez inefficace avec de nombreux petits fichiers. Cependant, ce n'est probablement pas votre problème principal qui est ...

Ext4 n'est pas bien adapté aux gros systèmes de fichiers avec des millions de fichiers. Utilisez XFS . J'ai des systèmes de fichiers XFS fonctionnant aussi gros que 1,2 PB et avec jusqu'à 1 milliard de fichiers, pas de problème. Utilisez simplement XFS .

Merci à tous ceux qui ont répondu à ma question.

Voici comment je l'ai résolu:

Tout d'abord, j'ai ajouté la quantité maximale de RAM à la carte. Malheureusement, la carte ne prend en charge que 64 Go de RAM. J'ai observé le comportement après l'expansion et c'était décevant. Bien que toute la RAM disponible ait été utilisée pour IO Cache, les performances de la sauvegarde RSNAPSHOT ne se sont pas améliorées de manière mesurable.

J'ai donc dû tirer la grosse masse. J'ai ajouté deux disques NVME de 1 To et les ai assemblés sur un RAID 1. Le RAID 6 composé de 8 disques durs de 10 To a été démonté en un RAID 1 (composé de 2x 10 To de disque dur, ext4) et un RAID 5 (composé de 6 x 10 To de disque dur). Le RAID 1 contient désormais le système d'exploitation et la copie de travail des serveurs (qui sont synchronisés 4 fois par jour sur ce disque).

Le RAID5 est maintenant un périphérique soutenu par BCACHE, soutenu par le NVME-RAID 1 et formaté avec ext4. Ce lecteur contient les copies RSNAPSHOT. Chaque nuit, les fichiers sont synchronisés du RAID1 au RAID5, ce qui réduit de moitié le débit d'E / S du RAID5 par rapport à l'ancien RAID6, qui contenait les copies de travail ET les instantanés de sauvegarde. Grâce au BCache, pas littéralement chaque fichier n'est écrit sur les disques, mais toutes les modifications d'un bloc sont écrites une seule fois, même s'il contient plusieurs centaines de modifications de fichier unique. Cela a encore réduit les IOps sur les disques durs.

Enfin, j'ai changé ma configuration RSnapshot. Auparavant, il y avait 31 instantanés quotidiens et 18 instantanés mensuels, ce qui entraînait 49 générations de sauvegarde. Maintenant, j'ai le design classique 7d / 4w / 12m / 1y, qui réduit le nombre de générations de sauvegarde à 24.

Après ces changements (et avec les 64 Go de RAM mentionnés ci-dessus), la durée d'un instantané est passée de ~ 20 heures à 1,5 heure. Les appareils BCache ont un taux de succès en cache de 82% (après 6 semaines de fonctionnement normal).

Mission accomplie. Merci à tous pour vos réflexions et vos commentaires.