This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!



I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!

Comprendre les stats I/O de zfs

French community

Moderators: velivole18, ernie, mtiburs

Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
User avatar
velivole18
Forum Moderator
Forum Moderator
Posts: 647
Joined: 14 Jul 2012 20:23
Location: France
Status: Offline

Comprendre les stats I/O de zfs

Post by velivole18 »

Bonjour,

Voici ce que me rapportent mes stats I/O de mon pool zfs :

Code: Select all

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pools1      1.80T  1.82T      2     20  55.3K   844K
  mirror     923G   933G      1     10  27.7K   422K
    ada4        -      -      0      7  13.1K   423K
    ada2        -      -      0      7  14.7K   423K
  mirror     924G   932G      1     10  27.6K   422K
    ada3        -      -      0      7  14.1K   424K
    ada1        -      -      0      7  13.6K   424K
cache           -      -      -      -      -      -
  aacd0     7.48G  22.3G      0      4    934   413K
----------  -----  -----  -----  -----  -----  -----
On peut y voir en particulier la dernière ligne faisant apparaitre mon disque SSD utilisé en cache zfs.
Comment lire les 2 dernières colonnes ? Quelle est la signification par exemple de 934 en read et 413K en write du disque SSD ?
Ces infos sont-elles suffisantes pour savoir si je tire avantage de mon cache sur disque SSD ou pas ?

Merci pour vos éclaircissements.
Cordialement
11.2.0.4 - Omnius (revision 6026) x64-embedded
111909 RSDT1411 AMD Athlon(tm) 64 Processor 4000+ 4096MiB RAM - HDD 2 x 6 To in ZFS mirroring + 2 x (2 x 4To in ZFS mirroring) - SSD 32Go - UPS EATON Ellipse MAX 1100.

sleid
PowerUser
PowerUser
Posts: 774
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by sleid »

Bonjour velivole18,
pour ce qui est de ces statistiques, il faut savoir qu'elles affichent la moyenne depuis le démarrage du NAS donc affectées par des srub ou autres lectures/écritures de métadonnées.
En brut ces stats montent que votre cache est utilisé uniquement en lecture et à priori de façon efficace.

Pour le voir plus finement il faut jouer avec les arguments de iostat.
zpool iostat vous affiche les statistiques du pool
zpool iostat -v vous affiche les même statistiques que dans l'interface ZFS c'est à dire le pool et les vdev

plus intéressant dans votre cas:

zpool iostat -v t(temps en secondes) i(nombre d'itérations) vous affiche les statistiques d'une durée t i fois.

Si vous lancez une commande zpool iostat -v 2 100 et que pendant ce temps vous faites des transferts avec votre NAS vous allez voir les statistiques toutes le 2 secondes pendant 200 secondes et là vous allez voir exactement comment se comporte votre cache.
12.1.0.4 - Ingva (revision 7852)
FreeBSD 12.1-RELEASE-p12 #0 r368465M: Tue Dec 8 23:25:11 CET 2020
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 WDC WD40EFRX + 3 WDC WD40EFRX

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 951
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by mtiburs »

Bonjour à tous,

Personnellement, j'utilise zpool iostat - v 1 et je m'attarde sur le read, plus le read est utilisé sur le cache et moins il sera utilisé sur le pool et mieux c'est.

Il y a 3 possibilité qui peuvent être réglé avec zfs get secondarycache monpool, c'est:
secondarycache=all (ZFS mets le plus possible de chose en cache)
secondarycache=metadata (ZFS ne mets que les méta-données dans le cache)
secondarycache=none (ZFS utilise le cache mais au minimum, attention "none", ne veut pas dire qu'il ne l'utilise pas ! il doit l'utiliser juste pour le minimum)

J'aurais tendance à dire que si on a un SSD:
- si on n'utilise peu sa machine, on met "none" et on use moins les cellules du SSD (c'est moins vrai avec le TRIM, mais l'usure existe toujours)
- si on utilise moyennement sa machine, on met metadata et on aura un compromis entre usure moindre du SSD et efficacité du cache
- si on veut tartiner, on met ALL, mais là, on écrit beaucoup de chose dessus.

A savoir, pour une raison voulue, le cache et perdu à chaque démarrage ou importation du pool, dans ton cas Velivole, tes 7,48Go de cache seront perdus lors de l'arrêt de ta machine.
Normalement, un NAS est fait pour fonctionner H24, mais les "normalement" ... sont une norme, pas forcément la réalité, certains arrêtent leurs NAS pour avoir moins de bruit ou pour consommer moins de courant..

Les réglages du secondarycache s'applique aussi au primarycache, qui lui est le cache RAM:
- si on met none, ZFS chargera en RAM le minimum qu'il a besoin
- si on met metadata, ZFS aura sous la main "des choses"
- si on met all, on aura le maxi "des choses" en cacheRAM, mais la quantité de RAM diminue aussi

Au vu des statistiques que tu as mis, je dirais que tes disques sont relativement lents et que l'utilisation d'un SSD est plus que nécessaire !

Pour affiner mes réglages, je ne mets pas de cache, j'utilise que le pool et je regarde avec: zpool import -v 1 (on arrête avec CTRL-C):
Si le read est à 2 digits, c'est que ça peine
Si le read est à 3 digits, c'est que ça marche bien
Si le read est à 4 digits, c'est que ça "tartine" bien
(Je suis d'accord que 1000 et 9999 est un peu différent, donc, on va dire que 1000 sur une config "faible" est bien)
Ensuite,
J'active le cache en secondary=none
là j'essaie d'avoir des read égaux ou superieurs au pool
Si c'est pas bon,
Je mets secondarycache=metadata
et je regarde de nouveau les stats
Idem pour all

Le but, n'est pas forcément d'avoir un gros cache, car plus il est gros, plus il faudra que ZFS se ballade dedans, c'est bien si le cache est en SSD, mais dans le cas d'un cache en disque dur, là ça peut être un soucis.
Le but (mon avis), est d'avoir un système ZFS "réactif", c'est à dire qu'en cas d'utilisation, ZFS puisse trouver ses infos rapidement.
Après il est évident que si tout est en cache dans un SSD, c'est mieux, de plus, cela sollicite moins les disques durs, ZFS a été conçu pour une utilisation SSD

Dans ton cas, Velivole, soit le cache est plus que nécessaire, soit il est réglé trop fort (il faudrait voir a quelle vitesse augment la taille du cache).
Si le NAS est H24, c'est bien (ne change rien).
Si le NAS est allumé tous les jours, alors, le SSD sera usé (plus) rapidement (essaie metadata et regarde si les perfomances te suffisent)

Pour l'analyse:
Pour le 934, c'est une lecture de 934 octets sur le SSD
Pour le 431K, c'est une écriture des 431Ko sur le SSD
On voit qu'il y a 7 opérations en écritures sur chaque disques (strip), donc 2 x 7, soit 14 opérations en cours. La totalisation est de 20, car l'écriture du SSD n'est pas comptabilisée car elle ne fait pas partie du pool
les écritures sur le SSD sont normales, car toutes écritures sur le pool, sont répercutées aussi sur le SSD (je serais quand même curieux de connaître la valeur du secondarycache)

on voit également, qu'il y a eu une lecture sur chaque branches du mirroir, mais ceci ne doit concerner que des cheksum sur la structure du mirroir, car il n'y a pas de valeurs dans les dev.

Mais il faudrait voir ce tableau avec un rafraîchissement de 1 sec sur une période plus longue, pour mieux voir, car là, c'est comme analyser une image sur une vidéo.

Surtout, en cas de doute ou de non réponse du pool, il faut venir voir ceci, car quand on efface de grosses données, le travail de ZFS peut durer "un certain temps".

Quelles sont tes valeurs maxi en read ? en write ? ceci pour une branche du mirroir et pour le SSD

N'hésite pas a regarder aussi lors d'un scrub. D'ailleurs a ce propos, un scrub permet indirectement de charger son cache ;) ... pas très pratique, je suis d'accord !


Pour finir, je dirais que tu as une bonne optimisation de ton système ... en lecture, pour l'écriture ... là c'est pas pareil :|
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas :o ... et pas à jour en plus :oops: (çà craint)
Conception d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.

User avatar
velivole18
Forum Moderator
Forum Moderator
Posts: 647
Joined: 14 Jul 2012 20:23
Location: France
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by velivole18 »

Bonjour,

Merci beaucoup pour vos réponses à vous deux ! :P
Je pense que cela va être utile à tous ceux qui sont curieux sur l'optimisation de leur système zfs.
C'est aussi pour cela que j'ai posté cette question.
Quand à moi, je vais prendre le temps de comprendre ce que vous me dites, faire des tests et voir ce qui peut être amélioré (en tout 1er lieu ma bonne compréhension du sujet ! :? )
Après bien des péripéties sur mon serveur (pb avec disques durs, carte mère HS, ...) me voilà maintenant avec un serveur tel que j'en avais envie depuis longtemps.
J'ai profité des différentes pannes sur mon serveur et donc de l'obligation de quelques achats pour le remettre sur pieds pour investir dans un disque SSD Transcend de 32Go à 37€.
J'en profite pour redire encore ma foi en zfs, car après bien des soucis sur mon serveur ces derniers temps, je n'ai encore une fois absolument rien perdu !
Je ne m'interdis pas de reposer quelques questions sur le sujet au fur et à mesure de mes tests et de mes incompréhensions et donc peut-être à très bientôt sur le sujet.

Cordialement.
11.2.0.4 - Omnius (revision 6026) x64-embedded
111909 RSDT1411 AMD Athlon(tm) 64 Processor 4000+ 4096MiB RAM - HDD 2 x 6 To in ZFS mirroring + 2 x (2 x 4To in ZFS mirroring) - SSD 32Go - UPS EATON Ellipse MAX 1100.

User avatar
velivole18
Forum Moderator
Forum Moderator
Posts: 647
Joined: 14 Jul 2012 20:23
Location: France
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by velivole18 »

Bonjour,

Pour répondre rapidement à mtiburs, voici les infos de mon serveur (c'est le paramétrage d'origine auquel je n'ai pas touché) :

Code: Select all

nas4free: ~ # zfs get secondarycache pools1
NAME    PROPERTY        VALUE           SOURCE
pools1  secondarycache  all             default
nas4free: ~ # zfs get primarycache pools1
NAME    PROPERTY      VALUE         SOURCE
pools1  primarycache  all           default
nas4free: ~ # 
Le Nas est très peu utilisé dans la journée, plutôt le soir lorsque je suis rentré du travail.
Il est soumis à du travail plutôt batch que transactionnel car je travaille en local sur mes machines linux et je synchronise des répertoires entiers toutes les 5 mn. par un outil de synchronisation (FreeFileSync).

Questions :
1 - les 2 colonnes de droite, ce sont des Ko/seconde ?
2 - Pourquoi indiquer 934 en read dans la colonne bandwidth alors qu'il est indiqué 0 en nombre d'opération read pour le disque SSD ?
3 - En quoi vois-tu que mon serveur est bon en lecture mais pas en écriture ?
4 - J'ai effectué l'expérience de copier un gros répertoire du NAS vers un client 2 fois de suite pour voir la différence, puis l'inverse, en enregistrant les stats dans un fichier en cours d'opération. J'en conclus tout d'abord que faire une seule fois la commande "zpool iostat" ne veut rien dire car elle n'a de sens que pour la mesure à l'instant t et l'instant d'avant ou d'après pouvait être très différent. Une analyse d'un enregistrement au cours d'une opération est plus pertinent. Es-tu d'accord avec cet avis ?

Je regarde les résultats et vous en fait part dans quelques temps.

Merci à tous.
Cordialement.
11.2.0.4 - Omnius (revision 6026) x64-embedded
111909 RSDT1411 AMD Athlon(tm) 64 Processor 4000+ 4096MiB RAM - HDD 2 x 6 To in ZFS mirroring + 2 x (2 x 4To in ZFS mirroring) - SSD 32Go - UPS EATON Ellipse MAX 1100.

sleid
PowerUser
PowerUser
Posts: 774
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by sleid »

Bonjour,
1 Normalement c'est le nombre d'I/O de blocs de 8ko (taille des blocs zfs affichée) mais j'ai un doute sous NAS4Free je pencherai plutôt pour des ko
2 ce sont des i/o ou octets donc la transaction de démarrage et plus rien après
3 je dirai plutôt le contraire.
4 je me répète:
Si vous lancez une commande zpool iostat -v 2 100 et que pendant ce temps vous faites des transferts avec votre NAS vous allez voir les statistiques toutes le 2 secondes pendant 200 secondes et là vous allez voir exactement comment se comporte votre cache.
C'est 200 secondes d'observations en continu avec affichage toutes les 2 secondes mais vous pouvez mettre les valeurs qui vous conviennent le mieux.
Si vous transférez vers le NAS vous devez avoir dans la colonne de droite des M au lieu des K et vice et versa.
L'utilisation du SSD sera également affichée.

Je pense que ce sont certainement des octets sous freebsd car comme j'atteins 70 à 80 M d'i/o sur des greens...je doute qu'il s'agisse de blocs de 8 k
12.1.0.4 - Ingva (revision 7852)
FreeBSD 12.1-RELEASE-p12 #0 r368465M: Tue Dec 8 23:25:11 CET 2020
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 WDC WD40EFRX + 3 WDC WD40EFRX

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 951
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Comprendre les stats I/O de zfs

Post by mtiburs »

Bonjour à tous,

Je reprends ce que j'avais mis dans un post plus haut: "Faire une analyse sur juste une vue d'écran d'un zpool iostat est identique à faire une analyse d'une seule image a propos d'un film entier".

Comme le dit Sleid, il faut faire des opérations IO en ayant une répétition sur le zpool iostat.

Sinon, j'ai trouvé ceci:

alloc capacity
Capacité utilisée, c'est-à-dire quantité de données actuellement stockées dans le pool ou le périphérique. Cette quantité diffère quelque peu de la quantité d'espace disque disponible pour les systèmes de fichiers effectifs en raison de détails d'implémentation interne.

free capacity
Capacité disponible, c'est-à-dire quantité d'espace disque disponible dans le pool ou le périphérique. Comme la statistique used, cette quantité diffère légèrement de la quantité d'espace disque disponible pour les jeux de données.

read operations
Nombre d'opérations de lecture d'E/S envoyées au pool ou au périphérique, y compris les demandes de métadonnées.

write operations
Nombre d'opérations d'écriture d'E/S envoyées au pool ou au périphérique.

read bandwidth
Bande passante de toutes les opérations de lecture (métadonnées incluses), exprimée en unités par seconde.

write bandwidth
Bande passante de toutes les opérations d'écriture, exprimée en unités par seconde.

J'ai dis que ton nas était optimisé en lecture par l'utilisation du SSD, et, qu'en écriture, il l'était moins ... en fait, y'à un peu de faux là-dedans, car, le fait d'avoir optimisé la lecture par le biais du SSD, laisse du coup plus de possibilité pour l'écriture.
En fait, je pensais à une autre structure :roll:
Ton Nas est très bien monté.

Après, si on veut chercher la petite bête, faut voir comment sont montés les disques et sur quoi, si ils sont sur un pont-sud en SATA, c'est moins bien que des disques SAS qui sont sur un pont-nord par le PCIe (le SATA est en NCQ, et le SAS en TCQ, qui lui permet d'avoir une profondeur de "queue" optimisé (en fait un enchaînement optimisé des opérations)
Donc, en fonction de l'architecture, du type, et de la qualité du matériel (disque de stockage ou disque rapide), le nombre d'opérations sera plus ou moins importants.
Ce nombre d'opérations correspond aux transactions ZFS sur le pool.
En regardant les stats, il est bien que le nombre d'opération soit important et ce dans les deux sens (read et write), il faut aussi que le bandwich soit le plus élevé mais de façon constante, il faut le moins d’à-coups.

Pour moi, ton système est optimisé surtout en lecture -sur le temps d'accès- grâce au SSD (tes disques durs ne peuvent pas rivaliser avec les "temps d'accès" du SSD).
L'optimisation est homogène grâce au montage "entrelacé et mirroir", qui dans les vrais termes est un "pool de stockage à deux miroirs bidirectionnels utilisant un entrelacement dynamique", c'est une très bonne structure à mon goût, car elle allie sécurité et performance. J'aime bien ce concept car elle laisse la porte ouverte a certains montages (par exemple ajouter du mirroir en iscsi pour travailler sur les disques locaux si besoin)

Après, il n'est pas évident de dire ce qui est bien ou pas, ça dépend de l'utilisation aussi (des tas de petits fichiers ou des gros).
Dans le cas ou l'on n'a pas de SSD, on peut mettre le cache en metadata, pour que les premiers éléments viennent rapidement à ZFS, et ensuite il va chercher sur les disques.
Ce qui est bien avec ZFS, c'est qu'on peut régler le cache en fonction du matos qu'on a (none, metadata ou all).

Pour une optimisation en écriture, il faudrait mettre deux disques en log (mirroir) et passer le sync à always, là, les donnés viendront se mettre tranquillement dans cette zone, puis une fois le travail fait, tout sera rangé sur le pool.
Certains disent qu'on peut mettre du SSD pour le log, perso, je suis réticent en cas de fortes écritures (mais c'est mon avis), car si le log "vit" beaucoup, le nombre d'écritures dans les cellules du SSD seront importantes, je suis plus pour de bons disques durs en privilégiant le SAS.
Ceci étant, souvent le log n'est pas franchement utile pour une utilisation "normale". J'ai souvent mis du log, et, je l'ai souvent enlevé car pas assez de sollicitations.

Question:
Après avoir fait un scrub complet, combien as-tu en nombres d'opérations/read lors d'un scrub suivant ? (valeur maximum)
Quel est le débit donné par un zpool status lors du premier scrub et lors du second ?

Un test qui serait bien, c'est de voir le taux de transfert, mais il faut qu'il soit cohérent, je veux dire pas limité par le débit de l'appareil qui reçoit les données.
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas :o ... et pas à jour en plus :oops: (çà craint)
Conception d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.

Post Reply

Return to “Français”