Perf I/O dégueu sur VM avec disque NVMe virtuel

christiane15 04/03/2026
RÉSOLU
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

Hello la team, on a des VMs KVM sur des hôtes avec du NVMe physique, mais les perfs I/O sur ces VMs sont vraiment à chier. C'est du virtio-scsi avec des disques que j'ai configuré en cache=none,io=native. On s'attendait à des trucs de fou mais on est au niveau d'un HDD à plateaux. Genre, un simple dd prend 10x plus de temps que sur l'hôte physique.

# exemple dd sur la vm
dd if=/dev/zero of=testfile bs=1m count=1024 oflag=direct

Je pige pas, y a un truc que je rate dans la chaîne ?

04/03/2026 à 14:34

10 commentaires

edouard78
Membre
Avatar de edouard78
edouard78
Membre

salut ! t'as regardé ton iostat -x pendant que tu fais un test ? voir si le util est haut et si le await ou svctm sont élevés. et c'est quel type de workload ? random read/write, sequential ?

Modifié le 23/05/2026 à 16:20
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

oui j'ai iostat. le util est à 99% mais les tps sont ridicules, genre 20-30 tps pour des block devices nvme. await est à plusieurs centaines de ms. c'est du mix, plutôt de la petite écriture/lecture random, c'est pour une base de données

Modifié le 23/05/2026 à 16:20
maurice42
Membre
Avatar de maurice42
maurice42
Membre

ok 99% util et tps faibles c'est un bottleneck clair. sur le NVMe physique côté hôte c'est quoi le scheduler I/O ? et côté VM ? avec cat /sys/block/sdX/queue/scheduler ou nvmeXnX pour NVMe direct

Modifié le 23/05/2026 à 16:20
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

sur l'hôte c'est none (nvme direct) normal. sur la VM c'est bfq. est-ce que ça peut avoir un impact énorme même avec io=native ?

Modifié le 23/05/2026 à 16:20
edouard78
Membre
Avatar de edouard78
edouard78
Membre

ah bfq pour une BDD avec du random I/O c'est pas idéal. bfq est super pour les workloads desktop interactifs mais pas pour des serveurs. essaie de passer la VM en mq-deadline ou même none si c'est du virtio-blk (pas virtio-scsi). ça peut aider beaucoup

Modifié le 23/05/2026 à 16:20
vrenaud
Membre Actif
Avatar de vrenaud
vrenaud
Membre Actif

oui bfq c'est un tue-la-performance pour du random io intensif. si tu es en virtio-scsi mq-deadline est souvent le meilleur compromis. sinon t'as check si tu utilises io_uring dans ton applicatif ? ça peut aussi booster pas mal si bien implémenté

Modifié le 23/05/2026 à 16:20
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

ok je vais tester mq-deadline sur la VM. je relance mes tests et je vois. pour io_uring non pas encore, l'appli utilise des appels standards. je me concentre sur l'infra pour l'instant.

Modifié le 23/05/2026 à 16:20
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

bon, mq-deadline a bien amélioré les choses ! les await ont chuté. on est pas encore au niveau de l'hôte mais c'est bien mieux. y a encore des gains possibles ou c'est le mieux qu'on puisse avoir avec virtio-scsi ?

Modifié le 23/05/2026 à 16:20
maurice42
Membre
Avatar de maurice42
maurice42
Membre

si tu peux passer en virtio-blk au lieu de virtio-scsi ça peut apporter un petit plus, c'est un peu plus simple et direct. mais le gros gain c'était le scheduler. après il y a toujours un overhead de virtualisation mais ça devrait être minimal avec du bon tuning.

Modifié le 23/05/2026 à 16:20
christiane15
Auteur Actif
Avatar de christiane15
christiane15
Auteur Actif

je peux tester virtio-blk sur une autre VM. je vais faire ça. merci pour tous les conseils, ça m'a bien aidé à comprendre la chaîne I/O virtuelle !

Modifié le 23/05/2026 à 16:20

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire