Vitesse du disque : baseline et burst

Le disque d'un VPS est en NVMe, mais la vitesse est limitée par le palier afin qu'une seule machine n'accapare pas la ressource partagée du nœud. Comprendre ces chiffres vous évite la question « pourquoi la base de données est-elle lente alors que le CPU est libre ».

Comment c'est calculé

Le débit d'écriture de base est de 60 Mo/s par cœur, mais jamais inférieur à 60 ni supérieur à 400 Mo/s. La lecture correspond au double du débit d'écriture de base. Au-delà de la base, un burst de trois fois sa valeur est disponible pendant 30 secondes.

Le burst couvre ce qu'il doit couvrir : le démarrage d'une application, l'extraction d'une archive, l'application d'une migration. Un flux d'écriture continu — copie de gigaoctets, build, analyse d'une grande base de données — tourne au débit de base.

Comment mesurer

sudo apt install -y fio
fio --name=w --rw=write --bs=1M --size=2G --numjobs=1 \
    --runtime=60 --time_based --end_fsync=1 --directory=/var/tmp

Les premières secondes afficheront un burst, puis la vitesse retombera au débit de base — c'est l'image normale et attendue, pas une anomalie.

Une vérification rapide et approximative sans installer de paquets :

dd if=/dev/zero of=/var/tmp/testfile bs=1M count=2048 oflag=direct
rm /var/tmp/testfile

Ne lancez pas de tests de disque sur une machine de production pendant les heures de travail. Le test consommera réellement toute la bande passante disponible, et votre site mettra plusieurs secondes à répondre pendant ces minutes. Et ne laissez pas traîner de fichiers de test : deux gigaoctets sur un disque de 40 Go représentent une part notable, voir espace disque.

Comment reconnaître que le disque est le goulot d'étranglement

sudo apt install -y sysstat
iostat -x 2 5
vmstat 2 5

Regardez deux métriques : un %util proche de 100 et un await de l'ordre de la dizaine de millisecondes indiquent une file d'attente sur le disque. Dans vmstat, le signe est le même — une colonne b (processus en attente) qui grossit avec un pourcentage d'utilisation du CPU faible.

Autre symptôme : un load average élevé avec un CPU presque au repos. Le load average de Linux compte aussi les processus en attente du disque.

Qui écrit exactement :

sudo iotop -o -b -n 3

Que faire si vous avez atteint le goulot d'étranglement

• Étalez-les dans le temps. Copies, builds de registre, rapports — la nuit et pas en même temps. Voir tâches planifiées.
• Limitez les tâches d'arrière-plan. rsync --bwlimit, nice -n 19 ionice -c3 <command> pour tout ce qui n'est pas urgent.
• Réduisez les écritures. Limitez la taille des logs, désactivez la verbosité excessive dans l'application, déplacez le cache en mémoire (tmpfs) s'il survit à un redémarrage.
• Optimisez la base de données. Dans PostgreSQL et MySQL, la part du lion des écritures revient au journal de transactions. Plus de mémoire pour les tampons signifie moins d'accès disque.
• Passez à un palier supérieur. Le débit de base augmente avec les cœurs : de VDS-1 à VDS-2, il double. Les changements de palier ne sont possibles qu'à la hausse, avec un paiement supplémentaire pour les jours restants de la période payée.

Erreurs courantes

• Mesurer la vitesse avec dd sans oflag=direct. Les données s'installent dans le cache de pages et les chiffres ressortent gonflés.
• Prendre un burst pour un débit soutenu. Les 30 premières secondes sont rapides, puis c'est le débit de base — c'est voulu.
• Garder le swap sur le disque actif et swapper dedans. Quand la mémoire manque, le swap transforme le disque en goulot d'étranglement : mieux vaut limiter les conteneurs, voir limites de ressources.