perfs i/o disque pourries sur nos vms linux comment diagnostiquer

première chose oui `iostat` c la base. regarde les `%util` et `await`. si `await` est très élevé alors que `%util` est faible c ptete des soucis de fragmentation ou de latence. si les deux sont hauts c la queue du disque qui est saturée.

sur tes vms c'est quelle config de disques ? virtio-blk sur kvm ? paravirtualisé sur vmware ? et côté host la config du storage c'est quoi ? raid ? ssd ? nvm-e ? un slow i/o sur la vm peut venir d'un disque saturé sur l'hyperviseur partagé avec d'autres vms.

check le scheduler i/o de ton kernel. `cat /sys/block/sdX/queue/scheduler`. pour les vms souvent `noop` ou `deadline` sont meilleurs que `cfq` qui est plutôt pour les disques physiques rotatifs. change-le avec `echo noop > /sys/block/sdX/queue/scheduler` (temporaire) ou `grub` (persistant).

aussi les options de montage filesystem. `noatime` ça aide à réduire les écritures inutiles sur les inodes. et si t'es sur ext4 avec un journal ça peut être utile de tester `barrier=0` sur des workloads non critiques mais attention au risque de corruption en cas de crash.

c quel type de workload qui fait ramer ? petits fichiers, gros fichiers, random read/write, sequential ? ça impacte le choix des optimisations. si c de la bdd les petits random writes sont les pires.

ok alors le iostat montre `%util` souvent à 100% et `await` très haut, genre 100-200ms parfois. c'est du virtio-blk sur kvm, le host est sur du raid6 ssd. la workload c'est des applis java qui font beaucoup d'accès logs et qqs accès bdd locale.

100% util et `await` à 200ms c clair ça pue. ça sent la saturation. vu que c du raid6 ssd côté host et virtio-blk c bizarre. tu as testé le scheduler i/o ? et `fio` c la commande ultime pour vraiment benchmarker tes perfs i/o dans la vm.

# exemple fio pour random write 4k
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/testfile

sur kvm vérifie la config du cache disque de la vm. `cache=none` est souvent recommandé pour les perfs dans un contexte de raid hardware. si t'as `writeback` ou `writethrough` ça peut être ok aussi mais `none` est le plus direct.

le `queue_depth` aussi peut jouer. c'est la profondeur de la file d'attente i/o. par défaut c'est souvent 128 ou 256. tu peux le tweak mais c'est avancé. et le `num_queues` si tu as plusieurs cpus virtuels, tu peux aligner le nombre de queues avec le nombre de vcpus pour mieux paralléliser.

j'ai switché le scheduler à `noop` et testé `fio`. ça a l'air un peu mieux mais pas encore le nirvana. `cache=none` est déjà configuré. je vais regarder le `num_queues` et le `queue_depth`. et aussi l'option `noatime` sur les points de montage logs.

ok good. si `fio` montre toujours des chiffres bas après ces tweaks alors c'est peut-être l'hyperviseur ou le storage backend du host qui a un souci, ou une saturation globale. un autre truc à voir c'est si les `dirty_ratio` et `dirty_background_ratio` du kernel linux ne sont pas trop agressifs et causent des stalls.

merci à tous pour les conseils super détaillés ! j'ai pas mal de billes pour continuer l'investigation. je vais remonter ça à l'équipe infra. c'est super utile !