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

17

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!

Pavel
la source

Réponses:

9

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 .

ewwhite
la source
Merci! Il n'y a pas de moyen équitable dans notre environnement d'utiliser des quotas, donc tout le monde utilise le même point de montage et peut remplir l'espace, ce qui entraîne une baisse des performances. Mon idée était de garantir un espace libre avec une réservation afin que le système global ne soit jamais trop lent. Mais IIUC, je peux avoir cette garantie en limitant volumeà 8.5T et ne plus jamais y penser. Est-ce exact?
Pavel
Vous pourriez .. ou simplement regarder. Je veux dire, c'est NFS ... pas un zvol, vous pouvez donc supprimer des fichiers pour revenir sous 8,5 To.
ewwhite
Oui, mais c'est pénible d'avoir ces discussions "s'il vous plaît nettoyer votre sh .., le serveur de fichiers est terriblement lent" dans les listes de diffusion toutes les deux semaines ...
Pavel
Solution technique à un problème social / administratif :) Rassemblez-vous anticiper autant de données?
ewwhite
Hehe .. Oui, c'est une situation assez courante à laquelle nous sommes confrontés. Ainsi, des affirmations comme celle-ci: "Sur les systèmes de fichiers avec de nombreuses créations et suppressions de fichiers, l'utilisation doit être maintenue à moins de 80% pour protéger les performances." imprécis, car il s'agit vraiment de l'espace libre dans un pool plutôt que du système de fichiers?
Pavel
21

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 1 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: dégradation des performances de zpool

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 2 , mais vous pourrez le conduire à 95% d'utilisation sans trop de tracas.


1 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

2 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.

le-wabbit
la source
syneticon-dj, merci pour cette explication! L'augmentation de la RAM semble effectivement aider.
Pavel
Qu'en est-il du BPR (réécriture du pointeur de bloc)? De plus, celui-ci blogs.kent.ac.uk/unseenit/2013/10/02/… mentionne également l'utilisation d'un SLOG pour ZIL. Et ce gars nex7.blogspot.com.au/2013/03/readme1st.html dit que vous envoyez et recevez jusqu'à ce que tout soit bien.
CMCDragonkai
@CMCDragonkai Je peux vous assurer par expérience que l'utilisation d'un périphérique ZIL distinct ne fait rien pour les performances en raison de la fragmentation de la carte spatiale. Mais ne pas avoir de périphérique ZIL augmentera la fragmentation globale et vous serez plus susceptible de rencontrer le problème à des pourcentages inférieurs d'utilisation de l'espace. BPR est toujours un vaporware - aucun code démontrable n'existe, encore moins une implémentation stable. Un cycle d' émission-réception est en effet susceptible d'aider à obtenir une piscine défragmenté, mais cela va vouloir dire des temps d' arrêt pour l'envoi / réception du jeu de données.
the-wabbit
Et si vous répliquiez l'ensemble de données avant d'envoyer-recevoir sur un autre disque? Et puis il suffit de faire pivoter un cycle d'envoi-réception pour chaque disque?
CMCDragonkai
@CMCDragonkai, vous pouvez réduire les temps d'arrêt en effectuant d'abord un envoi complet et en travaillant ensuite avec des incrémentiels. Mais les temps d'arrêt restent. Si vous utilisez vos ensembles de données comme stockage backend pour les bases de données ou la virtualisation, les temps d'arrêt font mal, même s'ils sont courts. De plus, vous aurez besoin d'un pool séparé et vide pour que cela fonctionne.
le-wabbit