Optimiser les performances NVMe sur Linux : I/O scheduler et tuning

Pour optimiser NVMe Linux dans un environnement de production, il est essentiel de maîtriser les paramètres du noyau, les pilotes spécifiques et les réglages du système de fichiers. Les disques NVMe offrent des performances exceptionnelles grâce à leur interface PCIe, mais encore faut-il que le système d'exploitation exploite pleinement cette architecture. Ce guide technique détaille les configurations avancées pour tirer le meilleur parti de vos périphériques SSD SAS sous Linux, notamment sur les VPS Linux OmegaCloud équipés de stockage SSD SAS.

Vérifier et comprendre l'infrastructure SSD SAS sous Linux

Avant d'optimiser SSD SAS Linux, il convient d'identifier précisément le matériel en place. La commande lsblk liste tous les périphériques de blocs, tandis que nvme list (paquet nvme-cli) affiche les détails spécifiques aux disques NVMe :

sudo apt update && sudo apt install nvme-cli -y
sudo nvme list
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,ROTA

La colonne ROTA doit afficher 0 pour les périphériques NVMe, confirmant l'absence de pièces rotatives. Notez le chemin du périphérique (par exemple /dev/nvme0n1) et le modèle du contrôleur. Utilisez ensuite :

sudo nvme id-ctrl /dev/nvme0n1 | grep -i mdts
sudo nvme id-ctrl /dev/nvme0n1 | grep -i volatile

Le paramètre MDTS (Maximum Data Transfer Size) indique la taille maximale de transfert prise en charge par le contrôleur. Un MDTS élevé permet au noyau Linux de soumettre des requêtes plus volumineuses, réduisant l'overhead du CPU. Vérifiez également la présence du cache volatile (si le fabricant en a équipé le disque) qui impacte les stratégies d'écriture.

Les disques NVMe modernes supportent plusieurs queues d'I/O, exploitées nativement par le pilote nvme du noyau. Contrairement aux anciens pilotes SCSI ou SATA, le pilote NVMe crée une paire de queues par cœur CPU, permettant un parallélisme maximal. Consultez les statistiques actives :

cat /sys/block/nvme0n1/queue/nr_requests
cat /sys/block/nvme0n1/queue/scheduler

La valeur nr_requests définit la profondeur de la queue logicielle du noyau. Par défaut, elle est souvent à 128 ou 256. Pour les charges de travail intensives (bases de données, analytics, CI/CD), augmenter cette valeur à 1024 peut réduire la latence perçue lors de pics d'activité. Le scheduleur d'I/O (scheduler) doit être [none] ou [noop], car les disques NVMe gèrent leur propre ordonnancement interne ; les scheduleurs classiques (mq-deadline, bfq) ajoutent un overhead inutile.

Réglages kernel et paramètres sysctl pour optimiser NVMe Linux

Le noyau Linux expose plusieurs tunables qui influencent directement les performances des périphériques NVMe. Le fichier /etc/sysctl.conf ou /etc/sysctl.d/99-nvme.conf permet de rendre ces paramètres persistants au redémarrage. Voici les réglages recommandés pour un serveur de production :

# Augmenter la taille de la queue du bloc pour NVMe
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 1000
vm.dirty_writeback_centisecs = 100

# Augmenter le nombre de requêtes en attente
# (à appliquer également via udev, voir plus bas)
# Diminuer la swappiness pour privilégier la RAM
vm.swappiness = 10

# Optimiser le cache VFS
vm.vfs_cache_pressure = 50

Appliquez immédiatement ces paramètres avec :

sudo sysctl -p /etc/sysctl.d/99-nvme.conf

Le paramètre dirty_ratio contrôle le pourcentage de mémoire RAM pouvant contenir des pages "sales" (non encore écrites sur disque) avant que le noyau ne bloque les processus en écriture. Sur un VPS avec 8 Go de RAM, un ratio de 10 % autorise 800 Mo de tampon d'écriture, permettant au NVMe de traiter les écritures par rafales. dirty_background_ratio déclenche le flush en arrière-plan, évitant les blocages brusques.

Pour ajuster dynamiquement nr_requests et d'autres paramètres spécifiques au périphérique NVMe, créez une règle udev. Exemple dans /etc/udev/rules.d/60-nvme-tuning.rules :

ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none", ATTR{queue/nr_requests}="1024", ATTR{queue/read_ahead_kb}="256"

Rechargez les règles et appliquez :

sudo udevadm control --reload-rules
sudo udevadm trigger

Le paramètre read_ahead_kb définit la taille de lecture anticipée. Sur un NVMe, 256 Ko est un compromis efficace entre latence et débit séquentiel. Augmenter à 512 Ko peut bénéficier aux workloads de streaming (logs, backups), mais dégrader les accès aléatoires en lecture.

Enfin, désactivez les fonctionnalités inutiles qui introduisent de la latence. Si votre workload n'utilise pas de snapshots LVM ou RAID, montez vos partitions avec les options noatime et nodiratime dans /etc/fstab :

/dev/nvme0n1p1  /data  ext4  defaults,noatime,nodiratime,discard  0  2

L'option discard active le TRIM automatique, permettant au contrôleur NVMe de récupérer les blocs libérés et de maintenir les performances en écriture sur le long terme. Remontez la partition sans redémarrer :

sudo mount -o remount /data

Choix du système de fichiers et optimisations avancées

Le système de fichiers joue un rôle déterminant dans l'exploitation des capacités d'un disque NVMe. Ext4 reste un choix solide, stable et bien documenté. Pour optimiser NVMe Linux avec ext4, utilisez les options de montage suivantes :

sudo mkfs.ext4 -F -E lazy_itable_init=0,lazy_journal_init=0,stride=128,stripe_width=128 /dev/nvme0n1p1
sudo tune2fs -o journal_data_writeback /dev/nvme0n1p1

Les paramètres stride et stripe_width alignent les blocs d'allocation sur les caractéristiques internes du NVMe (taille de page NAND). Le mode journal_data_writeback écrit les métadonnées dans le journal mais pas les données elles-mêmes, réduisant la charge d'écriture au prix d'une perte de cohérence en cas de crash brutal (acceptable sur un VPS avec anti-coupure N+1 comme chez OmegaCloud).

XFS excelle pour les gros fichiers et les I/O parallèles. Ses allocateurs de blocs (AG, Allocation Groups) se prêtent bien aux architectures multi-queues des SSD SAS. Formatage recommandé :

sudo mkfs.xfs -f -d agcount=8,su=64k,sw=1 -l size=128m /dev/nvme0n1p1

L'option agcount=8 crée huit groupes d'allocation, exploitant efficacement les huit cœurs d'un CPU moderne. su=64k (stripe unit) et sw=1 (stripe width) s'alignent sur la largeur de bloc typique des NVMe. Le journal de 128 Mo est dimensionné pour absorber les rafales d'écriture sans saturer.

Pour les environnements nécessitant des snapshots instantanés, du copy-on-write et une gestion avancée des volumes, Btrfs ou ZFS sont envisageables. Btrfs est intégré au noyau mainline Linux, contrairement à ZFS qui nécessite des modules tiers (OpenZFS). Exemple de création d'un volume Btrfs optimisé NVMe :

sudo mkfs.btrfs -f -d single -m single -L data /dev/nvme0n1p1
sudo mount -o noatime,nodiratime,compress=zstd:3,ssd,space_cache=v2 /dev/nvme0n1p1 /data

L'option ssd active les heuristiques spécifiques aux périphériques à état solide. compress=zstd:3 applique une compression transparente niveau 3, réduisant l'usure du disque et augmentant le débit effectif sur des données texte ou logs. space_cache=v2 accélère l'allocation de blocs libres. Attention : Btrfs en RAID5/6 reste déconseillé en production (risque de corruption en cas de panne), préférez -d single ou -d raid1 sur plusieurs NVMe.

Quel que soit le système de fichiers, activez le TRIM périodique via systemd. Sur Debian/Ubuntu, le timer fstrim.timer s'active par défaut. Vérifiez son statut :

sudo systemctl status fstrim.timer
sudo systemctl enable fstrim.timer
sudo fstrim -av

La commande fstrim -av effectue un TRIM manuel sur toutes les partitions montées avec l'option discard. Sur un VPS NVMe, cette opération prend quelques secondes et peut récupérer plusieurs gigaoctets de blocs libres, restaurant les performances d'écriture.

Benchmarking et validation des performances NVMe

Une fois les réglages appliqués, validez les gains de performance avec des outils de benchmark. fio (Flexible I/O Tester) est la référence pour mesurer les IOPS, la latence et le débit. Installez-le :

sudo apt install fio -y

Test de lecture aléatoire 4K (simule une base de données clé-valeur) :

fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=4G --numjobs=4 --runtime=60 --group_reporting --filename=/data/fio-test

Test d'écriture séquentielle 1M (simule un backup ou un log stream) :

fio --name=seqwrite --ioengine=libaio --iodepth=16 --rw=write --bs=1m --direct=1 --size=4G --numjobs=1 --runtime=60 --group_reporting --filename=/data/fio-test

Les SSD SAS atteignent typiquement 500 000 IOPS en lecture aléatoire 4K et 3 à 5 Go/s en lecture séquentielle sur un VPS dédié. Sur un environnement virtualisé KVM comme celui des VPS Linux OmegaCloud, attendez-vous à 200 000–300 000 IOPS et 2–3 Go/s en fonction de la contention. Si les résultats sont inférieurs de plus de 30 %, revisitez les paramètres nr_requests, le scheduleur et les options de montage.

Pour mesurer la latence réelle (perçue par l'application), utilisez ioping :

sudo apt install ioping -y
ioping -c 100 /data

Une latence inférieure à 100 µs (0,1 ms) en lecture confirme que le noyau et le driver NVMe fonctionnent correctement. Des latences supérieures à 500 µs peuvent indiquer un problème de cache, une file d'attente saturée ou un swap actif (vérifiez free -h et augmentez la RAM si nécessaire).

Enfin, surveillez en temps réel les métriques NVMe avec iostat (paquet sysstat) :

sudo apt install sysstat -y
iostat -xz 2 nvme0n1

Les colonnes %util, r/s, w/s et await donnent une vue instantanée de la charge. Un %util proche de 100 % signale une saturation, tandis qu'un await élevé (>10 ms) indique une latence excessive. Le panel OmegaCloud affiche également des graphiques temps réel de l'utilisation disque, CPU et réseau, permettant de corréler les pics d'I/O avec les événements applicatifs.

Conclusion

Optimiser NVMe Linux nécessite une approche multicouche : pilotes et noyau à jour, paramètres sysctl ajustés, système de fichiers correctement configuré, et validation par benchmarks. En appliquant ces réglages sur un VPS NVMe haute performance, vous exploitez pleinement la bande passante et la latence sub-milliseconde du stockage PCIe, assurant fluidité et réactivité pour bases de données, conteneurs, CI/CD et applications critiques. Un suivi régulier via iostat, fio et les outils du panel d'administration garantit la pérennité des performances.

FAQ

Dois-je activer le TRIM en continu (discard) ou périodique (fstrim.timer) sur un NVMe Linux ?

Le TRIM périodique via fstrim.timer est recommandé pour la majorité des cas. L'option de montage discard effectue un TRIM synchrone à chaque suppression de fichier, ce qui peut introduire de la latence sur des workloads intensifs en écriture. Le timer hebdomadaire suffit à maintenir les performances du contrôleur NVMe sans impacter la réactivité du système.

Quel impact a le paramètre nr_requests sur la latence des requêtes NVMe ?

Le paramètre nr_requests définit la profondeur maximale de la queue logicielle du noyau. Une valeur trop faible (128) provoque des blocages lorsque plusieurs processus écrivent simultanément, augmentant la latence moyenne. Passer à 1024 réduit les pics de latence de 30 à 50 % sur des charges de production (bases de données, CI/CD), sans coût CPU significatif grâce au modèle multi-queue du pilote NVMe.

Ext4, XFS ou Btrfs pour un serveur de production avec NVMe sous Linux ?

Ext4 offre stabilité et performances éprouvées, idéal pour la majorité des usages (web, applications métier). XFS excelle sur les gros fichiers et les I/O parallèles (analytics, logs). Btrfs apporte snapshots et compression transparente, mais nécessite une surveillance accrue (espace libre, fragmentation). Sur un VPS NVMe, ext4 avec noatime, discard et journal_data_writeback reste le choix le plus pragmatique.