Performance ZFS 10GbE : prouver si le réseau est le goulot d’étranglement

Un modèle mental qui survit aux réunions

Pour prouver un goulot d’étranglement, vous devez séparer les plafonds de débit de l’amplification de latence et de la sérialisation.

1) Le 10GbE a un plafond dur, mais votre charge l’atteint différemment

Sur le papier, 10GbE fait 10 gigabits par seconde. En pratique, le meilleur débit utile TCP est généralement autour de 9,4–9,8 Gbit/s selon le framing, les offloads et le CPU. Cela représente environ 1,1–1,2 GB/s en termes de copie de fichiers si tout est aligné et en streaming.

Mais les charges ZFS ne sont pas toujours en streaming. Des I/O petites, du bavardage métadonnées, des écritures synchrones, ou un protocole bavard peuvent « dépenser » du débit en overhead et « perdre » du temps en allers-retours. Le 10GbE peut sembler lent alors qu’il est en fait rapide mais contraint à un comportement stop-and-wait par quelque chose en amont.

2) ZFS peut être plus rapide que votre réseau, et c’est un piège

Un pool ZFS moderne avec suffisamment de disques ou de NVMe peut dépasser 10GbE en lectures séquentielles. Parfait. Cela signifie que le réseau devient le limiteur sur les transferts volumineux, et vous devriez voir un plateau net : les disques ne sont pas très sollicités, le CPU n’est pas saturé, et la NIC est proche du débit de ligne.

Si vous ne voyez pas un plateau net, vous n’êtes pas « limité par le réseau ». Vous êtes « limité par autre chose » et le réseau est juste impliqué.

3) Prouver un goulot réseau requiert deux mesures indépendantes

Vous cherchez à répondre à une question précise : Le réseau est-il le point le plus étroit dans ce chemin de bout en bout ?

Pour le prouver, vous avez besoin de :

• Un test réseau seul (sans disques, sans systèmes de fichiers) qui approche le débit de ligne.
• Un test stockage seul (local au serveur) qui dépasse ce que vous observez sur le réseau.
• Puis un test combiné (NFS/SMB/iSCSI) qui correspond au plafond réseau seul.

Si l’un d’eux ne s’aligne pas, vous n’avez pas un goulot réseau net. Vous avez un problème en couches, plus agaçant mais aussi plus corrigeable.

Règle opérationnelle à s’afficher : Ne jamais tuner ZFS pour un problème réseau, et ne jamais tuner le réseau pour un problème ZFS, sans tests d’isolation.

Faits intéressants et courte histoire (pour arrêter les mythes)

• Le 10GbE n’a pas été d’abord conçu pour le cuivre bon marché. Les premières déploiements étaient majoritairement en fibre ; 10GBASE-T est arrivé plus tard et consommait plus d’énergie comparé aux optiques SFP+/DAC.
• Les jumbo frames précèdent la popularité du 10GbE. Elles étaient utilisées pour réduire la charge CPU sur des liens très occupés bien avant que chaque switch ne « puisse les supporter » par défaut.
• ZFS a été conçu avec l’intégrité des données de bout en bout comme caractéristique principale. Checksums et copy-on-write ne sont pas des « extras » ; c’est le cœur, et cela a des implications de performance.
• NFS a vécu plusieurs vies. v3 est sans état et courant sur les appliances ; v4 ajoute état, verrouillage, et différents modes de défaillance qui apparaissent comme des « problèmes de performance ».
• La performance SMB a évolué drastiquement avec le multi-channel et les stacks modernes. Les vieilles recettes de tuning SMB continuent d’être collées dans des environnements qui ne correspondent pas.
• La mise à l’échelle de la fenêtre TCP a rendu possibles les liens haut-débit et haute-latence. Sans elle, votre « 10GbE » se comporterait comme une suggestion polie.
• La modération d’interruptions et les offloads sont un compromis. Ils réduisent le coût CPU par paquet, mais peuvent aussi augmenter la latence ou masquer des bugs de pilote.
• recordsize de ZFS n’est pas la même chose que « taille de bloc sur disque », mais influence fortement le pattern d’I/O et donc l’efficacité du streaming par les protocoles réseau.
• Les buffers des switches ne sont pas infinis, et les micro-bursts peuvent faire tomber des paquets même quand l’utilisation moyenne semble correcte.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : prouver que le réseau peut faire du 10GbE entre les deux hôtes exacts

• Exécutez iperf3 dans les deux sens avec plusieurs flux.
• Vérifiez la vitesse négociée de la NIC, le PCIe width, le pilote et les erreurs.
• Recherchez des pertes/retransmissions. Si vous en voyez, arrêtez-vous et corrigez cela avant de toucher à ZFS.

Second : prouver que le serveur ZFS peut lire/écrire plus vite en local que ce que voit le client

• Utilisez fio localement contre un dataset (et éventuellement un zvol) avec direct I/O pour éviter les illusions « c’est juste l’ARC ».
• Utilisez zpool iostat -v pour confirmer que les disques font bien ce que vous croyez.
• Surveillez l’utilisation CPU et la latence par périphérique ; si le pool ne peut pas fournir 1+ GB/s, le réseau n’est pas le goulot principal.

Troisième : tester le protocole réel (NFS/SMB/iSCSI) et corréler des deux côtés

• Exécutez un transfert de fichier contrôlé ou fio sur NFS/SMB.
• Capturez simultanément : stats NIC, stats ZFS, et retransmissions côté client.
• Si le débit du protocole correspond au plafond iperf3 et que les disques serveur sont sous-utilisés, vous êtes limité par le réseau (par conception, pas par accident).

Si vous ne faites qu’une seule chose : lancez iperf3 et capturez les retransmissions. Si le réseau est malade, il se dénoncera vite.

Repères de base pour 10GbE + ce qu’est « bon »

Les cibles varient selon l’OS, la NIC et le CPU. Mais pour un lien 10GbE unique sur Linux moderne :

• iperf3 flux unique : souvent 6–9 Gbit/s selon le tuning TCP et la latence.
• iperf3 4–8 flux parallèles : devrait approcher 9,4–9,8 Gbit/s sur un LAN propre.
• Retransmissions TCP : doivent être proches de zéro sur un LAN stable. Quelques-unes pendant le warm-up peuvent arriver ; des retransmissions persistantes signifient des pertes, des optiques/câbles défectueux, des problèmes de négociation duplex/vitesse, ou une pression de buffer.
• Erreurs/drops NIC : doivent être nulles ou extrêmement faibles. « Un peu » n’est pas un plan.
• Lecture séquentielle locale serveur (fio) : idéalement > 1.2 GB/s si vous voulez saturer 10GbE avec marge ; sinon votre pool est le limiteur.

Également : n’ignorez pas le client. Beaucoup d’incidents « le NAS est lent » viennent en fait d’un driver NIC client du Paléolithique sur un portable.

Blague #1 : Un lien 10GbE qui plafonne à 2 Gbit/s est toujours « 10GbE » dans le même sens qu’une voiture de sport sur une crevaison est toujours « une voiture de sport ».

Tâches pratiques : commandes, sorties, décisions

Ce sont de véritables tâches que vous pouvez exécuter aujourd’hui. Chacune inclut une commande, une sortie d’exemple, et la décision à prendre. Exécutez-les sur le serveur ZFS et sur le client quand applicable.

Task 1: Verify link speed, duplex, and negotiated state

cr0x@server:~$ sudo ethtool enp65s0
Settings for enp65s0:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: No
        Advertised link modes:  10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

Ce que cela signifie : Si vous ne voyez pas 10000Mb/s Full avec Link detected, stoppez. Vous ne pouvez pas sur-tuner un lien défectueux.

Décision : Si la vitesse n’est pas 10Gb, corrigez câblage/optiques/config switch d’abord. Si un mismatch d’auto-négociation existe (commun avec 10GBASE-T), corrigez-le.

Task 2: Check PCIe link width/speed (yes, it matters)

cr0x@server:~$ sudo lspci -s 65:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L0s, Exit Latency L0s <512ns, L1 <64us
LnkSta: Speed 8GT/s, Width x8

Ce que cela signifie : Une NIC 10GbE dans un slot PCIe qui tourne en x1 ou à basse vitesse peut plafonner le débit ou provoquer des pics de latence sous charge.

Décision : Si width/speed est en dessous de l’attendu, déplacez la NIC, changez les paramètres BIOS, ou arrêtez de partager les lanes avec un HBA stockage si la carte mère est avare.

Task 3: Check interface error counters and drops

cr0x@server:~$ ip -s link show dev enp65s0
2: enp65s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  1234567  0       0        0       1234
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  2345678  0       0        0       0

Ce que cela signifie : Tout erreur/dropped non nul pendant le test est suspect. Dropped peut aussi être un overflow de file d’attente hôte.

Décision : Si les drops augmentent sous charge, investiguez tailles de rings, pilote, affinité IRQ, et congestion du switch. Ne touchez pas ZFS encore.

Task 4: Look for TCP retransmits on Linux (client and server)

cr0x@server:~$ sudo nstat -az | egrep "TcpRetransSegs|TcpOutSegs|TcpInErrs"
TcpInErrs                    0                  0.0
TcpOutSegs                   4863921            0.0
TcpRetransSegs               12                 0.0

Ce que cela signifie : Les retransmissions doivent être extrêmement faibles sur un LAN. Des retransmissions persistantes indiquent perte de paquets ou réordonnancement sévère.

Décision : Si les retransmissions augmentent significativement pendant un test de débit, réparez le chemin réseau (câbles/optiques, buffers de switch, hashing LACP, mismatch MTU) avant d’accuser ZFS.

Task 5: Establish raw network throughput with iperf3 (server mode)

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 10.20.30.41, port 49822
[  5] local 10.20.30.10 port 5201 connected to 10.20.30.41 port 49824
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.8 GBytes  9.27 Gbits/sec

Ce que cela signifie : 9+ Gbit/s est un bon signe. Si vous êtes coincé à 3–5 Gbit/s, le réseau ou la pile hôte limitent.

Décision : Si iperf3 ne peut pas aller vite, ne perdez pas de temps à tuner NFS/SMB/ZFS. Réparez le tuyau basique d’abord.

Task 6: Use multiple streams to reach line rate

cr0x@client:~$ iperf3 -c 10.20.30.10 -P 8 -t 15
[SUM]   0.00-15.00  sec  17.1 GBytes  9.80 Gbits/sec                  receiver

Ce que cela signifie : Multi-flux masque souvent les limitations d’un seul flux (taille de fenêtre, ordonnancement CPU, quirks d’offload).

Décision : Si multi-flux atteint ~9.5–9.8 mais le flux unique est faible, le réseau est correct ; concentrez-vous sur le tuning TCP, le CPU, et le comportement de l’application/protocole (copie mono-thread, écritures sync, petits I/O).

Task 7: Validate MTU end-to-end (no fragmentation, no wishful thinking)

cr0x@client:~$ ping -M do -s 8972 10.20.30.10 -c 3
PING 10.20.30.10 (10.20.30.10) 8972(9000) bytes of data.
8972 bytes from 10.20.30.10: icmp_seq=1 ttl=64 time=0.215 ms
8972 bytes from 10.20.30.10: icmp_seq=2 ttl=64 time=0.207 ms
8972 bytes from 10.20.30.10: icmp_seq=3 ttl=64 time=0.209 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2035ms

Ce que cela signifie : Si ça échoue, vous n’avez pas de jumbo frames fonctionnelles sur le chemin. Le jumbo partiel est pire que l’absence totale.

Décision : Ou bien rendez l’MTU cohérent sur NICs/VLAN/ports switch, ou bien restez à 1500 partout et arrêtez d’en discuter.

Task 8: Check NIC offloads and sanity (TSO/GSO/GRO/RX/TX)

cr0x@server:~$ sudo ethtool -k enp65s0 | egrep "tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|rx-checksumming|tx-checksumming"
rx-checksumming: on
tx-checksumming: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Ce que cela signifie : Les offloads peuvent améliorer le débit et réduire le CPU, mais des pilotes/firmware bogués peuvent provoquer des drops ou des latences étranges.

Décision : Si vous observez retransmissions/drops et suspectez les offloads, basculez les fonctionnalités une par une pendant un test contrôlé. N’éteignez pas tout d’un coup « parce que Reddit ».

Task 9: Observe interrupt distribution (a single hot CPU can cap you)

cr0x@server:~$ grep -i enp65s0 /proc/interrupts | head
  72:  1203987   1123340   1189021   1098877   PCI-MSI 524288-edge      enp65s0-TxRx-0
  73:    23411     21987     24010     22022   PCI-MSI 524289-edge      enp65s0-TxRx-1
  74:    11234     10988     12001     11102   PCI-MSI 524290-edge      enp65s0-TxRx-2
  75:     9876      9455     10012      9666   PCI-MSI 524291-edge      enp65s0-TxRx-3

Ce que cela signifie : Si une seule file/CPU prend presque toutes les interruptions, vous atteindrez un plafond CPU avant le débit de ligne.

Décision : Si la distribution est biaisée, corrigez RSS/RPS/XPS, vérifiez irqbalance, et assurez-vous que plusieurs queues TX/RX sont actives.

Task 10: Confirm ZFS pool health and basic layout (no, resilvering doesn’t “not matter”)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:31:14 with 0 errors on Sun Dec 22 03:10:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
            sdg                     ONLINE       0     0     0
            sdh                     ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Si vous êtes en resilver, scrub, ou en état dégradé, vos conclusions de performance sont contaminées.

Décision : Ne réalisez des preuves de performance que sur un pool stable, sinon vous optimiserez pour un état d’urgence.

Task 11: Measure server-side disk throughput and latency while clients run

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        3.12T  21.8T    210    180   1.15G   320M
  raidz2-0                  3.12T  21.8T    210    180   1.15G   320M
    sda                         -      -     26     22    142M    40M
    sdb                         -      -     26     22    144M    39M
    sdc                         -      -     26     22    143M    40M
    sdd                         -      -     26     22    142M    40M
    sde                         -      -     26     22    143M    40M
    sdf                         -      -     26     22    143M    40M
    sdg                         -      -     26     22    144M    41M
    sdh                         -      -     26     22    144M    41M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Si votre pool lit à ~1.15G et votre NIC fait ~9.5 Gbit/s, le réseau pourrait être la limite. Si la bande passante du pool est bien en dessous et que les devices montrent des ops élevées, vous êtes limité par les IOPS/la latence.

Décision : Si le pool ne peut pas pousser localement au-delà de ce que vous observez sur le réseau, arrêtez d’incriminer le réseau.

Task 12: Measure local storage performance with fio (bypass cache illusions)

cr0x@server:~$ sudo fio --name=seqread --directory=/tank/test --rw=read --bs=1M --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --size=20G --runtime=30 --time_based
seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=32
fio-3.33
seqread: (groupid=0, jobs=1): err= 0: pid=28144: Fri Dec 25 10:12:01 2025
  read: IOPS=1342, BW=1342MiB/s (1407MB/s)(40.0GiB/30538msec)
    slat (usec): min=6, max=214, avg=17.32, stdev=7.11
    clat (msec): min=1, max=41, avg=23.76, stdev=4.12

Ce que cela signifie : Un BW de lecture local (~1.4 GB/s) dépasse ce que 10GbE peut transporter. Parfait : le stockage peut alimenter le lien.

Décision : Si le BW local est bien au-dessus de 1.2 GB/s mais que les lectures réseau sont bien plus faibles, le goulot est réseau/protocole/CPU, pas disques.

Task 13: Measure local synchronous write sensitivity (SLOG truth serum)

cr0x@server:~$ sudo fio --name=syncwrite --directory=/tank/test --rw=write --bs=16K --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --size=5G --runtime=20 --time_based --fsync=1
syncwrite: (g=0): rw=write, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=1
fio-3.33
syncwrite: (groupid=0, jobs=1): err= 0: pid=28410: Fri Dec 25 10:14:44 2025
  write: IOPS=820, BW=12.8MiB/s (13.4MB/s)(256MiB/20008msec)
    clat (usec): min=340, max=8241, avg=1169.55, stdev=422.12

Ce que cela signifie : Les écritures sync peuvent être brutalement limitées par la latence. Le débit semble « mauvais » car chaque écriture attend la durabilité.

Décision : Si votre appli/protocole est sync-heavy (bases de données, images VM, NFS avec sync), vous ne saturerez pas le 10GbE sans adresser la latence des sync (SLOG, réglages, design de la charge).

Task 14: Check ZFS dataset settings that influence streaming vs chatter

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,atime,compression,sync tank/data
NAME       PROPERTY     VALUE
tank/data  recordsize   1M
tank/data  atime        off
tank/data  compression  lz4
tank/data  sync         standard

Ce que cela signifie : recordsize influence l’efficacité séquentielle ; atime peut ajouter des écritures supplémentaires ; compression peut augmenter le débit apparent (si compressible) ou coûter du CPU.

Décision : Ne touchez pas à ces paramètres avant d’avoir prouvé la baseline réseau. Ensuite, tunez pour la charge : gros fichiers veulent recordsize grand ; petits aléatoires veulent plus petit et peut-être des stratégies vdev spécifiques.

Task 15: Observe CPU saturation and softirq pressure during transfer

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:16:11 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal  %idle
12:16:12 AM  all   12.4  0.0   18.1   0.7    0.0  22.8    0.0   46.0
12:16:12 AM   7   10.0  0.0   21.0   0.0    0.0  65.0    0.0    4.0
12:16:12 AM  15   11.0  0.0   20.0   0.0    0.0  62.0    0.0    7.0

Ce que cela signifie : Si un ou deux CPU sont presque saturés en %soft, vous êtes limité par la pile réseau-hôte, pas par la vitesse du lien. Cela ressemble à « 10GbE est lent » mais c’est en réalité « l’hôte ne peut pas pousser les paquets assez vite ».

Décision : Corrigez IRQ/RSS, envisagez un CPU plus rapide, une meilleure NIC/driver, ou ajustez le comportement du protocole (moins d’opérations petites, I/O plus grandes).

Task 16: Validate NFS mount and server export behavior (client-side)

cr0x@client:~$ nfsstat -m
/tank/data from 10.20.30.10:/tank/data
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.30.41,local_lock=none

Ce que cela signifie : De petits rsize/wsize ou une mauvaise version peuvent limiter fortement le débit. v4.1 avec 1M rsize/wsize est généralement sain pour le streaming volumineux.

Décision : Si rsize/wsize sont petits, corrigez les options de montage ou la config serveur. Si vous utilisez UDP (rare maintenant), arrêtez.

Task 17: Observe NFS client retrans and RPC behavior

cr0x@client:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
987654     12         0

Client nfs v4:
null         read         write        commit       open
0            120034       60012        0            320

Ce que cela signifie : Une augmentation des retransmissions corrèle avec perte réseau ou surcharge serveur. Cela tue le débit car RPC attend.

Décision : Si retrans augmente sous charge, investiguez pertes réseau ou contention CPU serveur ; n’augmentez pas timeo et appelez ça réglé.

Task 18: SMB server/client: verify multi-channel and throughput behavior

cr0x@server:~$ sudo smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-----------------------------------------------------------------------------------------------------------------------------
12011   alice        staff        10.20.30.41 (ipv4:10.20.30.41:52144)      SMB3_11           -                    partial(AES-128-GMAC)

Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         12011   10.20.30.41   Fri Dec 25 00:18:12 2025        -            partial(AES-128-GMAC)

Ce que cela signifie : Le signing/encryption SMB peut coûter du CPU ; multi-channel peut ou non être utilisé selon la config client/serveur.

Décision : Si le CPU est le limiteur et que le signing/encryption SMB est activé inutilement sur un LAN de confiance, discutez avec la sécurité pour ajuster. Si vous en avez besoin, prévoyez de la marge CPU.

Task 19: Track per-protocol throughput vs NIC throughput (server-side)

cr0x@server:~$ sar -n DEV 1 3
Linux 6.1.0 (server)  12/25/2025  _x86_64_  (32 CPU)

00:20:01     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
00:20:02   enp65s0   82000     79000     1150000   180000      0         0       120
00:20:03   enp65s0   83000     80000     1165000   175000      0         0       130

Ce que cela signifie : ~1 150 000 kB/s est ~1.15 GB/s en réception. C’est proche du plafond pratique du 10GbE pour la charge utile.

Décision : Si la NIC est proche du plafond mais que les utilisateurs se plaignent encore, vous saturerez probablement le lien ou subissez un partage injuste entre clients. Envisagez LACP (prudemment), liens plus rapides, ou QoS — pas des rituels recordsize ZFS.

Task 20: Check ZFS ARC and memory pressure (because “cache” hides problems)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
00:21:10   951    21      2     8   38    13   62     0    0   96G   112G
00:21:11  1002    24      2     9   37    15   63     0    0   96G   112G

Ce que cela signifie : Un miss% bas pendant les lectures suggère que l’ARC sert beaucoup. Votre « test de débit réseau » peut être en fait un test de RAM.

Décision : Pour la preuve, utilisez des tests direct I/O ou de grands jeux de travail. Si l’ARC fait le travail, c’est correct opérationnellement, mais n’attribuez pas cela à la performance disque à tort.

Cela fait plus d’une douzaine de tâches ; utilisez celles qui correspondent à votre stack. L’objectif n’est pas de collecter des trivia. L’objectif est de prendre une décision après chaque commande.

Interprétation des résultats : prouver le goulot

À quoi ressemble un « goulot réseau » réel

Vous pouvez qualifier le réseau de goulot quand les éléments suivants sont simultanément vrais :

• iperf3 entre les mêmes hôtes atteint ~9,4–9,8 Gbit/s avec peu de retransmissions.
• Le stockage local serveur peut dépasser 1,2 GB/s pour votre pattern d’accès (ou au moins dépasser ce que vous obtenez via NFS/SMB).
• Lors d’un accès réel, la NIC est proche du plafond tandis que les disques ne sont pas saturés et le CPU ne s’effondre pas en softirq.
• Les stats spécifiques au protocole (retrans NFS, stalls de crédit SMB, retrans iSCSI) ne montrent pas de pathologies.

Dans ce cas, félicitations : votre système fonctionne normalement. Vous avez atteint la physique et les standards. La solution est la capacité : plus de liens, des liens plus rapides, ou une meilleure distribution entre NICs/clients.

À quoi ressemble un cas « pas goulot réseau »

La plupart du temps, « 10GbE est lent » correspond à l’un de ces cas :

Cas A : perte de paquets et retransmissions sous charge

iperf3 peut sembler correct sur de courtes rafales, mais les transferts soutenus montrent des drops, retransmissions et effondrement du débit. Vous verrez TcpRetransSegs qui augmentent, des drops NIC, ou des discards sur le port switch. C’est un problème réseau—même si le lien est négocié à 10Gb.

Coupables courants : optiques/DAC défectueux, câble 10GBASE-T marginal, mismatch MTU provoquant fragmentation/blackholes, exhaustion des buffers de switch, uplinks over-subscription.

Cas B : goulot CPU/interrupt sur le serveur ou le client

La NIC est à 10Gb, mais l’hôte ne l’est pas. %soft élevé sur un CPU, interruptions inégales, ou boucle de copie mono-thread limitent souvent à 3–6 Gbit/s. Très courant sur les CPU plus anciens ou avec des defaults drivers malheureux.

Cas C : incompatibilité protocole/charge (petits I/O sur protocole bavard)

Le 10GbE brille sur les I/O séquentiels larges. Si votre charge est faite de petites lectures aléatoires, d’opérations métadonnées, ou d’écritures synchrones, votre débit sera déterminé par les IOPS et la latence, pas par la bande passante. Ce n’est pas un goulot réseau, c’est la réalité de la charge.

Cas D : latence d’écriture sync ZFS (et le mythe « SLOG va nous sauver »)

Si vous faites des écritures sync, le débit peut être minuscule tandis que le réseau reste inactif. Vous verrez faible MB/s, mais un grand nombre d’opérations et une latence élevée. Sans un SLOG adapté (et les attentes adéquates), vous ne réglerez pas cela avec des changements MTU.

Une citation à garder dans votre canal d’incident

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent attribuée dans les cercles d’ingénierie et d’exploitation

Que vous l’ayez entendue en postmortem ou non, le point reste : mesurer, isoler, décider.

Blague #2 : Si vous « améliorez » la performance 10GbE en désactivant les checksums, vous n’avez pas tuning un système — vous avez commis un délit contre la réalité.

Trois mini-histoires d’entreprise (pénibles, réelles, utiles)

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

L’équipe disposait d’un NAS ZFS servant des images VM via NFS à un petit cluster. Les tests stockage en local semblaient forts : lectures locales bien supérieures à 1 GB/s, latence apparemment correcte, tout le monde était satisfait. Puis le lundi matin, les démarrages VM saccadaient comme un film de zombies.

L’hypothèse immédiate fut classique : « NFS est lent » et « ZFS doit être tuné ». Quelqu’un proposa de changer recordsize, désactiver atime partout (correct, mais hors sujet), et jouer avec sync. L’équipe réseau disait que les liens 10GbE étaient « up », donc ce n’était pas eux.

Un SRE exécuta iperf3 et obtint 9.7 Gbit/s pendant 10 secondes. Affaire classée, non ? Sauf que la douleur survenait en charge soutenue. Ils relancèrent iperf3 pendant 10 minutes avec plusieurs flux et virent le débit en scie. Les retransmissions montèrent. Les compteurs de port du switch indiquèrent des discards intermittents.

Cause racine : le NAS et les hyperviseurs étaient connectés via une paire de switches leaf avec un uplink discrètement oversubscribed pendant les sauvegardes. Le lien était techniquement « 10GbE » et « sain », mais pas disponible quand il le fallait. L’erreur fut d’assimiler vitesse négociée et capacité réellement délivrée.

Correctif : déplacer le trafic de sauvegarde, ajouter de la capacité là où la contention existait, et ajouter de l’alerte basique sur les discards du switch et les retransmissions hôtes. Les réglages ZFS restèrent inchangés. Les problèmes de performance disparurent comme s’ils n’avaient jamais existé.

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait un serveur ZFS pour stockage média partagé sur SMB. Ils voulaient des transferts plus rapides de gros fichiers vidéo. Quelqu’un proposa les jumbo frames et poussa MTU 9000 sur le serveur et quelques postes. Le switch « supportait le jumbo », donc ça devait marcher.

Un jour, ça sembla aller mieux. Puis des tickets arrivèrent : blocages aléatoires, transferts gelant à 95%, parfois une copie repartait de zéro. Des captures Wireshark montrèrent des retransmissions TCP et des messages ICMP « fragmentation needed » qui n’étaient pas toujours délivrés.

Le problème n’était pas les jumbo frames en soi. C’était les jumbo frames partiellement déployées. Un segment de switch avait MTU 9000, un autre restait à 1500 à cause d’un interconnect plus ancien, et un firewall sur le chemin traitait les gros paquets comme suspects.

L’« optimisation » augmenta la probabilité de blackholing difficile à diagnostiquer et rendit le système moins fiable. Les moyennes de débit ont peut-être légèrement augmenté dans un cas étroit, mais la latence des queues et le taux d’échec des transferts empirèrent — ce qui est l’expérience réelle des utilisateurs.

Correctif : soit déployer jumbo bout en bout avec vérification (chaque saut et VLAN inclus), soit revenir à 1500 et se concentrer sur protocole et layout disque. Ils revinrent en arrière, puis améliorèrent les réglages SMB et la concurrence client. Résultat net : pics de débit un peu plus bas, beaucoup moins de blocages. Les utilisateurs arrêtèrent de se plaindre, ce qui est le seul benchmark qui compte.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un établissement financier faisait tourner un appliance ZFS pour des chargements nocturnes. Rien d’extraordinaire : NFS, quelques liens 10GbE, et un processus de changement strict. Leur arme secrète n’était pas un sysctl magique. C’était la discipline ennuyeuse.

Ils gardaient un runbook « baseline de performance » trimestriel : iperf3 entre hôtes connus, un fio local en lecture/écriture séquentielle, et un test protocole qui imitait la production (mêmes montages, mêmes credentials, même profondeur de répertoires). Ils archivaient les sorties dans le ticketing. Aussi excitant que regarder de la peinture sécher. Volontairement.

Un trimestre, la baseline iperf3 est passée de proche du débit de ligne à environ 6 Gbit/s. Personne ne s’était encore plaint. Ils traitèrent ça comme un incendie quand même, parce que les baselines ne mentent pas sans aide.

L’enquête trouva qu’une mise à jour BIOS avait réinitialisé des defaults de gestion d’énergie PCIe et avait poussé la NIC dans un état moins optimal sous charge. Le changement n’avait pas cassé la connectivité ; il avait juste réduit discrètement le débit. Grâce aux baselines, ils purent prouver la régression, l’isoler, et revenir aux bons réglages.

Leçon : des tests ennuyeux, exécutés régulièrement, détectent les problèmes avant que vos utilisateurs ne le fassent. « Mais ça marchait le mois dernier » devient « nous avons un diff ». C’est la maturité opérationnelle.

Erreurs courantes : symptôme → cause réelle → correctif

1) Symptom: “We only get 3–5 Gbit/s on 10GbE”

Cause réelle : Flux TCP unique limité (taille de fenêtre, CPU, affinité interrupt), ou client incapable de suivre.

Correctif : Validez avec iperf3 -P 8. Si multi-flux est rapide, adaptez la charge pour utiliser le parallélisme (threads de copie multiples), corrigez IRQ/RSS, ou améliorez CPU/NIC.

2) Symptom: Throughput spikes then collapses every few seconds

Cause réelle : Perte de paquets due à micro-bursts, exhaustion des buffers de switch, ou uplinks sur-subscription ; TCP réduit fortement.

Correctif : Vérifiez discards switch et retransmissions hôte. Réduisez la contention, ajoutez de la bande passante, ou appliquez QoS si pertinent. Ne touchez pas ZFS en premier.

3) Symptom: Large sequential reads are fast, writes are painfully slow

Cause réelle : Écritures sync (NFS/VM/bases) limitées par la latence ZIL ; pas de SLOG adapté ; ou SLOG non sûr contre perte de courant.

Correctif : Confirmez avec tests fio sync et caractéristique de la charge. Ajoutez un SLOG approprié seulement si la charge en bénéficie, et choisissez un device conçu pour faible latence et protection perte de puissance.

4) Symptom: “Jumbo frames improved one client but broke others”

Cause réelle : Mismatch MTU le long du chemin, ou domaines MTU mixtes sans routage/PMTUD correct.

Correctif : Soit déployez MTU bout en bout avec validation via ping -M do à la taille cible, soit standardisez sur 1500.

5) Symptom: SMB copy speed is low and CPU is high

Cause réelle : Overhead signing/encryption SMB, comportement client mono-thread, ou CPU serveur saturé dans la pile kernel/réseau.

Correctif : Mesurez le CPU et les réglages SMB. Décidez avec la sécurité s’il est possible d’assouplir signing/encryption sur un LAN de confiance ; sinon provisionnez du CPU et envisagez des changements de protocole.

6) Symptom: NFS stalls and “server not responding” messages appear

Cause réelle : Pertes/retrans réseau, serveur surchargé, ou pics de latence stockage provoquant des timeouts RPC.

Correctif : Vérifiez retrans NFS, retrans TCP, et latence serveur. N’augmentez timeo qu’après avoir corrigé la cause, pas comme sédatif.

7) Symptom: Great performance in synthetic tests, bad in production

Cause réelle : Benchmarks utilisent l’ARC, contournent les métadonnées, ou font du séquentiel contrairement à la charge réelle.

Correctif : Testez avec un working set plus grand que la RAM, utilisez --direct=1 pour fio, et imitez taille et concurrence d’I/O réelles.

8) Symptom: LACP added but a single client still can’t exceed ~10GbE

Cause réelle : LACP n’augmente pas le débit d’un flux unique ; le hashing attache les flux à un lien membre.

Correctif : Utilisez plusieurs sessions/clients, SMB multichannel, sessions NFS, ou passez à un lien unique plus rapide (25/40/100GbE) si le débit par hôte unique est requis.

Listes de contrôle / plan étape par étape

Plan étape par étape pour prouver (pas deviner) le goulot

1. Geler le champ de bataille : assurer qu’il n’y a pas de resilver/scrub, pas de tâches de fond majeures, et tester durant une fenêtre contrôlée.
2. Documenter la topologie : chemin exact client ↔ ports switch ↔ VLAN ↔ port serveur. Si vous ne pouvez pas le dessiner, vous ne pouvez pas le déboguer.
3. Valider lien et PCIe : ethtool, lspci, compteurs d’erreurs, drops.
4. Exécuter baseline iperf3 : flux unique, puis multi-flux, puis direction inverse. Capturer les retrans avant et après.
5. Valider politique MTU : soit 1500 partout soit jumbo partout. Prouver avec ping -M do.
6. Mesurer stockage local : fio lecture/écriture séquentielle avec --direct=1 ; optionnellement test d’écriture sync si pertinent.
7. Mesurer protocole réel : NFS/SMB/iSCSI avec un test représentatif. Gardez-le répétable.
8. Corréler pendant le test : zpool iostat serveur, débit NIC (sar), softirq CPU (mpstat), retrans client (nstat).
9. Prendre la décision : choisissez le point le plus étroit étayé par les données. Notez-le avec les sorties attachées.
10. Changer une chose : relancez le même test. Si vous changez trois choses, vous n’avez rien appris.

Checklist : signes que vous êtes vraiment limité par le réseau (la checklist « arrêter de tuner ZFS »)

• iperf3 stable proche du débit de ligne avec peu de retransmissions
• Débit NIC proche de 1.1–1.2 GB/s pendant lectures/écritures de fichiers
• Pool ZFS non saturé (bande passante et ops disques non maximales)
• CPU non saturé en softirq ou sur un seul cœur
• Stats protocole propres (pas de pic de retrans NFS, pas de stalls SMB)

Checklist : signes que le goulot est l’hôte/protocole, pas le lien

• iperf3 rapide en multi-flux mais flux unique lent
• %soft élevé ou interruptions biaisées pendant les transferts
• faible utilisation NIC alors que les utilisateurs attendent
• charge sync-heavy avec faible MB/s mais latence opération élevée
• haut taux de paquets/s (pps) avec petits I/O et ops métadonnées

FAQ

1) Quel débit dois-je attendre du 10GbE pour une grosse copie de fichier ?

Sur un LAN propre, attendez environ 1.0–1.2 GB/s en charge utile dans le meilleur des cas. Si vous voyez ~800–1100 MB/s sur des transferts séquentiels larges, vous êtes probablement correct.

2) Pourquoi iperf3 affiche 9.8 Gbit/s mais la copie SMB n’est que 400 MB/s ?

Parce que le tuyau réseau est sain, et quelque chose au-dessus ne l’est pas : coût CPU signing/encryption SMB, pattern I/O petit, mono-thread client, softirq serveur, ou comportement sync ZFS. Mesurez CPU et stats protocole pendant la copie.

3) Les jumbo frames améliorent-elles toujours les performances d’un NAS ZFS ?

Non. Elles peuvent réduire la charge CPU pour de forts taux de paquets, mais créent aussi des modes de défaillance si le chemin n’est pas configuré de manière cohérente. Si vous ne pouvez pas prouver MTU bout en bout, utilisez 1500 et avancez.

4) Dois-je désactiver les offloads NIC pour « réparer la performance » ?

Seulement si vous avez des preuves qu’ils causent des drops/retransmissions ou des pics de latence avec votre pilote/firmware spécifique. Basculez une fonctionnalité à la fois et retestez. Désactiver tout sans distinction augmente souvent l’utilisation CPU et réduit le débit.

5) LACP est-il la solution pour saturer 10GbE ?

LACP augmente la bande passante agrégée sur plusieurs flux, pas souvent pour un seul flux. Si un client a besoin de >10Gb/s, cherchez un lien unique plus rapide (25/40/100GbE) ou un protocole/client utilisant plusieurs canaux.

6) La compression ZFS peut-elle améliorer le débit réseau ?

Parfois, oui. Si vos données se compressent bien, le serveur envoie moins d’octets sur le réseau, donc le débit effectif augmente. Mais cela coûte du CPU. Mesurez débit et CPU avant de vous déclarer victorieux.

7) Comment savoir si je suis limité par les écritures sync ?

Si le débit d’écriture est faible, la latence élevée, et les tests avec fsync ou charges de base de données se comportent pareil, vous êtes probablement contraint par la latence de durabilité. Ajouter un SLOG approprié peut aider, mais seulement pour les écritures sync et seulement si le device est adapté.

8) Pourquoi la performance varie-t-elle selon l’heure de la journée ?

Généralement la contention : uplinks de switch oversubscribed, fenêtres de sauvegarde, réplication, ou voisins bruyants sur une infrastructure partagée. Prouvez-le en corrélant les baisses de débit aux retransmissions et aux discards de port switch pendant ces fenêtres.

9) Comment garder les tests honnêtes quand l’ARC rend tout excellent ?

Utilisez des jeux de travail supérieurs à la RAM, utilisez fio --direct=1, et répétez les runs après le warm-up du cache avec des tailles de fichier contrôlées. Ne benchmarkez pas la mémoire et n’appelez pas cela du stockage.

10) Si je suis vraiment limité par le réseau, quelles sont mes meilleures voies d’évolution ?

Ajoutez de la bande passante (25GbE est une étape courante), ajoutez du parallélisme (plusieurs NICs/clients), ou répartissez les charges sur plusieurs interfaces. Le choix dépend si vous avez besoin de débit par client ou de capacité agrégée multi-clients.

Prochaines étapes réalisables cette semaine

1. Exécutez et sauvegardez trois baselines : iperf3 (flux unique + multi-flux), fio local lecture séquentielle, et un test protocole (NFS/SMB) représentatif de la production.
2. Ajoutez deux alertes : retransmissions TCP hôte (client/serveur) et discards/drops de ports switch sur les ports côté NAS.
3. Décidez votre politique MTU : 1500 partout ou jumbo partout. Documentez et appliquez-la.
4. Choisissez un goulot à corriger : perte de paquets, softirq CPU, latence écriture sync, ou réelle saturation de lien. Ne tentez pas de tout réparer avec un sysctl magique.
5. Notez la preuve : collez les sorties de commandes dans votre ticket. Le vous du futur remerciera le vous du présent quand quelqu’un dira « c’était toujours comme ça ».

Si vous faites les tests d’isolation et que les chiffres ne sont toujours pas cohérents, ce n’est pas un échec. Ce sont des données indiquant que le système réel est plus intéressant que le diagramme. Bienvenue en production.