Performances ZFS: dois-je conserver de l'espace libre dans un pool ou un système de fichiers?

Je sais que les performances de ZFS dépendent fortement de la quantité d'espace libre:

Gardez l'espace du pool sous 80% d'utilisation pour maintenir les performances du pool. Actuellement, les performances du pool peuvent se dégrader lorsqu'un pool est très plein et que les systèmes de fichiers sont mis à jour fréquemment, comme sur un serveur de messagerie occupé. Les pools complets peuvent entraîner une baisse des performances, mais pas d'autres problèmes. [...] Gardez à l'esprit que même avec un contenu principalement statique dans une plage de 95 à 96%, les performances d'écriture, de lecture et de réargenture pourraient en souffrir. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Supposons maintenant que j'ai un pool raidz2 de 10T hébergeant un système de fichiers ZFS volume. Maintenant, je crée un système de fichiers enfant volume/testet lui donne une réservation de 5T.

Ensuite, je monte les deux systèmes de fichiers par NFS sur un hôte et effectue un travail. Je comprends que je ne peux pas écrire sur volumeplus de 5T, car les 5T restants sont réservés à volume/test.

Ma première question est, comment les performances chuteront-elles si je remplis mon volumepoint de montage avec ~ 5T? Va-t-il tomber, car il n'y a pas d'espace libre dans ce système de fichiers pour la copie sur écriture de ZFS et d'autres méta-trucs? Ou restera-t-il le même, puisque ZFS peut utiliser l'espace libre dans l'espace réservé à volume/test?

Maintenant la deuxième question . Cela fait-il une différence si je modifie la configuration comme suit? volumea maintenant deux systèmes de fichiers, volume/test1et volume/test2. Les deux reçoivent une réservation de 3T chacun (mais pas de quotas). Supposons maintenant que j'écris 7T test1. Les performances des deux systèmes de fichiers seront-elles les mêmes ou seront-elles différentes pour chaque système de fichiers? Va-t-il chuter ou rester le même?

Merci!

Oui. Vous devez conserver de l'espace libre dans votre piscine. C'est principalement pour les actions de copie sur écriture et les instantanés. Les performances diminuent à environ 85% d'utilisation. Vous pouvez aller plus haut, mais il y a un impact certain.

Ne jouez pas avec les réservations. Surtout avec NFS. Ce n'est pas nécessaire. Peut-être pour un zvol, mais pas pour NFS.

Je ne vois pas la confusion, cependant. Si vous avez 10T, n'en utilisez pas plus de 85%. Dimensionnez vos parts de manière appropriée, en utilisant des quotas pour limiter leur utilisation. Ou n'utilisez aucun quota et surveillez votre utilisation globale du pool .

La dégradation des performances se produit lorsque votre zpool est soit très complet soit très fragmenté. La raison en est le mécanisme de découverte de blocs libres utilisé avec ZFS. Contrairement à d'autres systèmes de fichiers comme NTFS ou ext3, il n'y a pas de bitmap de bloc indiquant quels blocs sont occupés et lesquels sont libres. Au lieu de cela, ZFS divise votre zvol en (généralement 200) zones plus grandes appelées «métaslabs» et stocke les arbres AVL ¹ des informations de blocs libres (carte spatiale) dans chaque métaslab. L'arbre AVL équilibré permet une recherche efficace d'un bloc correspondant à la taille de la demande.

Bien que ce mécanisme ait été choisi pour des raisons d'échelle, il s'est malheureusement avéré également être une douleur majeure lorsqu'un niveau élevé de fragmentation et / ou d'utilisation de l'espace se produit. Dès que toutes les métaslabs contiennent une quantité importante de données, vous obtenez un grand nombre de petites zones de blocs libres, par opposition à un petit nombre de grandes zones lorsque le pool est vide. Si ZFS doit ensuite allouer 2 Mo d'espace, il commence à lire et à évaluer toutes les cartes spatiales des métaslabs pour trouver un bloc approprié ou un moyen de diviser les 2 Mo en blocs plus petits. Bien sûr, cela prend un certain temps. Ce qui est pire, c'est que cela coûtera beaucoup d'opérations d'E / S car ZFS lirait en effet toutes les cartes spatiales des disques physiques . Pour n'importe lequel de vos écrits.

La baisse des performances peut être importante. Si vous avez envie de jolies photos, jetez un coup d'œil à l' article de blog sur Delphix qui a quelques chiffres retirés d'un pool zfs (simplifié mais néanmoins valide). Je vole sans vergogne l'un des graphiques - regardez les lignes bleues, rouges, jaunes et vertes dans ce graphique qui représentent (respectivement) des pools à 10%, 50%, 75% et 93% de capacité par rapport au débit d'écriture dans Ko / s tout en se fragmentant au fil du temps:

Une solution rapide et sale à cela a toujours été le mode de débogage du métaslab (il suffit de le lancer echo metaslab_debug/W1 | mdb -kwau moment de l'exécution pour changer instantanément le paramètre). Dans ce cas, toutes les mappes spatiales seraient conservées dans la RAM du système d'exploitation, supprimant la nécessité d'E / S excessives et coûteuses à chaque opération d'écriture. En fin de compte, cela signifie également que vous avez besoin de plus de mémoire, en particulier pour les grandes piscines, il s'agit donc d'une sorte de RAM pour le stockage du commerce de chevaux. Votre pool de 10 To vous coûtera probablement 2 à 4 Go de mémoire ² , mais vous pourrez le conduire à 95% d'utilisation sans trop de tracas.

¹ c'est un peu plus compliqué, si vous êtes intéressé, regardez le post de Bonwick sur les cartes spatiales pour plus de détails

² si vous avez besoin d'un moyen de calculer une limite supérieure pour la mémoire, utilisez zdb -mm <pool>pour récupérer le nombre de segmentsactuellement en cours d'utilisation dans chaque métaslab, divisez-le par deux pour modéliser le pire des cas (chaque segment occupé serait suivi par un segment libre ), multipliez-le par la taille d'enregistrement pour un nœud AVL (deux pointeurs de mémoire et une valeur, étant donné la nature de 128 bits de zfs et l'adressage 64 bits résumerait à 32 octets, bien que les gens semblent généralement supposer 64 octets pour certains raison).

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

Référence: le plan de base est contenu dans cet article de Markus Kovero sur la liste de diffusion zfs-discuter , bien que je pense qu'il a fait des erreurs dans son calcul que j'espère avoir corrigées dans le mien.