Performances I/O aléatoires sur VMs Linux critiques

salut! `await` élevé sur SAN ça fait penser au `io_scheduler`. t'es en quel scheduler? `cfq` par défaut est souvent pas top pour les SANs. faudrait tester `deadline` ou `noop`. `echo deadline > /sys/block/sdX/queue/scheduler`

et la version de ton kernel? des fois y'a des bugs i/o corrigés dans les nouvelles versions. et t'es bien avec les drivers virtuels genre `virtio_blk` pour la vm ou tu utilises encore des vieux trucs émulés? `lsmod | grep virtio`

vérifie aussi la queue depth de tes LUNs côté SAN et côté VM. si la VM envoie trop de requêtes et que le SAN en accepte moins ça peut backlog et créer des `await`. et des snapshots ou des réplications sur le SAN en arrière-plan? ça peut plomber les perfs

le scheduler est en `deadline` partout. kernel 5.15.x. et `virtio_blk` est bien chargé. côté san rien de spécial les autres vms sur les mêmes LUNs vont bien. pas de snapshots ou réplications qui tournent à ces moments-là

ok donc pas le scheduler classique. est-ce que c'est lié à des pics de workload sur les VMs? t'as des processus qui font des gros batchs i/o d'un coup? ou c'est random? regarde les métriques au niveau des cgroups ou du process avec `pidstat -d`

et les logs kernel (`dmesg -T`)? des erreurs disk, des timeouts scsi, des resets de bus? même si c'est du virtio, ça peut masquer un souci physique en dessous. un truc du genre `blk_update_request: I/O error`?

y'a pas une limite de connexions ou de débit réseau sur l'hyperviseur pour le trafic i/o? ou des ressources cpu allouées qui sont tirées à bloc sur le node physique? un `top` ou `htop` sur l'hyperviseur pendant un pic de latence peut donner un indice

non les logs kernel sont propres. pas d'erreurs disk. c'est des dbs donc beaucoup de petites écritures aléatoires et des lectures. ça peut être des pics de requêtes oui mais le cpu/mem de la vm est ok. c'est juste l'i/o qui se met à ramer

hmmm bizarre. est-ce que t'as joué avec les paramètres de cache du système de fichiers? `vm.dirty_ratio`, `vm.dirty_background_ratio`? si la vm accumule trop de pages sales en mémoire avant de les flusher sur le disk ça peut créer des latences monstrueuses quand le flush se produit

oui c'est une excellente piste. par défaut le `dirty_ratio` est à 20% et `dirty_background_ratio` à 10% de la ram. si ta vm a bcp de ram et beaucoup d'écritures ça peut faire des gros pauses. essaye de les baisser à 5 et 2% pour forcer des flush plus fréquents et plus petits

ah oui j'avais pas pensé à ça ! le `dirty_ratio` était bien à 20 et 10. je vais tester de baisser ça. je mets `vm.dirty_background_ratio = 2` et `vm.dirty_ratio = 5` via `sysctl` pour voir

normalement ça devrait lisser la charge i/o. le kernel va vider le cache plus souvent et éviter les gros à-coups. tiens nous au jus

alors le changement a eu un effet direct. les pics d'await sont quasi disparus. les perfs sont beaucoup plus stables maintenant. c'était bien le cache dirty du kernel qui mettait le bazar. un grand merci la team vous êtes au top!