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
An Error Occurred: Internal Server Error

Oops! An Error Occurred

The server returned a "500 Internal Server Error".

Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.