perf i/o disque random sur vm linux

ça sent l'i/o scheduler

par défaut sur les systèmes récents c'est souvent mq-deadline ou none si nvme

mais pour des vm sur un hyperviseur t'es mieux avec `noop` ou `none`

l'hyperviseur gère déjà l'ordonnancement disque donc ton OS fait du double taf

check cat /sys/block/sdX/queue/scheduler

oui `noop` c'est le best practice pour les vm et les disques ssd

si t'es sur `deadline` ou `cfq` ça peut introduire de la latence si y a pas mal de petites i/o

faut aussi regarder le `fio` ou `iostat` pendant les périodes de lenteur pour voir le `await` et `util`

effectivement je suis sur `mq-deadline` par défaut sur le volume de data

je vais tester de le passer à `noop`

vous avez des recommandations pour la taille des buffers ou les réglages `dirty_ratio` dans `sysctl` ?

pour les buffers `dirty_ratio` et `dirty_background_ratio` ça dépend beaucoup de ta ram et de ton workload

si t'as des gros bursts de writes ça peut aider d'augmenter un peu mais faut faire gaffe à pas allouer trop de ram pour le cache disque et bloquer le système

commence par `noop` c'est souvent le gros gain

n'oublie pas le `barrier=0` sur `ext4` dans ton fstab si t'as une batterie de cache sur ton san/hyperviseur

ça peut améliorer les perfs write mais attention si tu perds le courant sans write cache bien protégé tu risques de perdre des données

mais dans un environnement vmware avec un vsan ou un stockage bien géré c'est ok

aussi si t'es sur ext4 tu peux voir `commit=N` dans ton fstab pour réduire la fréquence des syncs

par défaut c'est 5s si j'me souviens bien tu peux le passer à 30 ou 60s pour les workloads où la consistance immediate est moins critique

mais attention à la perte de données en cas de crash

j'ai passé le scheduler à `noop` et c'est le jour et la nuit les perfs sont beaucoup plus stables et rapides

j'ai aussi mis un `commit=30` dans le fstab pour les volumes non critiques

énorme merci à vous pour les conseils c'était bien l'i/o scheduler le coupable