12 commentaires
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
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 !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la compagnie. on a des vms linux (centos/ubuntu) sur notre infra on-prem (kvm/vmware) et certaines ont des perfs i/o disque vraiment mauvaises. ça se ressent sur les applis qui tournent dessus. j'ai l'impression que c'est pas le stockage lui-même qui est lent mais plutôt un souci côté os ou vm. des commandes à lancer, des configs à vérifier pour comprendre d'où ça vient ?