Ce guide couvre les principes et les réglages les plus importants pour améliorer les performances d’un pool ZFS en production ou en lab. Il présente des choix pratiques pour recordsize, cache, compression, et des outils pour mesurer l’impact des changements.
Principes de base
ZFS combine système de fichiers et gestionnaire de volumes : les performances dépendent donc autant du matériel (disques, contrôleurs, RAM, réseau) que des paramètres ZFS. Avant de modifier des options, identifiez les goulots d’étranglement : latence disque, bande passante HBA, saturation CPU, ou contention réseau.
- Surveillez les IOPS et la latence pour déterminer si le problème est orienté lecture ou écriture.
- La mémoire disponible impacte fortement ARC (cache) : plus d’ARC = moins d’accès disque.
- Les workloads séquentiels et aléatoires posent des exigences différentes (recordsize, volblocksize).
Réglages de dataset recommandés
Les paramètres de dataset affectent directement la façon dont ZFS écrit et lit les données. Voici les options courantes à ajuster en fonction du workload.
recordsize
Choisissez recordsize en fonction de la taille typique des E/S applicatives :
- Workloads de bases de données avec E/S 8K : utiliser recordsize=8K.
- Fichiers volumineux séquentiels : privilégier recordsize plus grand (128K ou 1M).
- Attention : changer recordsize n’affecte pas les fichiers existants sans réécriture.
compression
La compression réduit la charge I/O si les données sont compressibles et si le CPU n’est pas un goulot.
- lz4 est un bon compromis performances/taux de compression.
- Désactivez la compression pour les données déjà compressées (médias, archives).
atime et autres
Désactiver atime peut améliorer les écritures intensives où l’accès aux timestamps n’est pas nécessaire :
- set atime=off pour réduire les écritures inutiles.
- Ajustez primarycache/secondarycache selon que vous souhaitez mettre en cache les métadonnées uniquement ou les données aussi.
Réglages au niveau du pool
Les choix de vdev et la configuration du pool sont critiques :
- Préférez vdevs équilibrés : mélanger disques rapides et lents dégrade la performance.
- Pour les petites IOPS, RAID-Z peut être acceptable ; pour des IOPS élevés, privilégiez mirror.
- ashift doit être défini correctement (par ex. ashift=12 pour 4K phys). Ne le changez pas après création sans recréer le pool.
Mesures et outils
Mesurer l’impact de vos réglages est indispensable. Utilisez des outils dédiés :
- fio pour simuler des charges I/O (tests séquentiels et aléatoires).
- iostat et vmstat pour surveiller l’activité disque et l’usage CPU.
- arcstat et zpool iostat pour suivre l’utilisation ARC et les statistiques du pool.
- smartctl pour vérifier la santé des disques physiques.
Procédez par tests contrôlés : changez un paramètre, exécutez un bench, comparez les mesures.
Étapes recommandées
- Collectez des métriques pour comprendre le goulot.
- Testez différentes valeurs de recordsize sur un dataset de test.
- Ajustez la compression et mesurez l’impact CPU vs I/O.
- Optimisez la topologie de vdev si possible (mirrors pour IOPS, RAID-Z pour capacité).
- Surveillez en continu avec des outils d’alerte et réévaluez périodiquement.
FAQ
Quelle taille de recordsize utiliser pour une base de données ?
Adaptez recordsize à la taille d’E/S typique : pour des blocs de 8K, utilisez recordsize=8K. Pour des accès majoritairement séquentiels, augmentez recordsize.
La compression impacte-t-elle les performances ?
Oui : si les données sont compressibles, la compression réduit les I/O et peut améliorer globalement les performances, à condition que le CPU soit suffisant. lz4 est généralement recommandé.
Comment savoir si ARC est le goulot ?
Surveillez le hit rate ARC via arcstat : un faible hit rate avec forte latence disque indique que plus de RAM pour ARC pourrait aider.