Kernel Linux : I/O wait énorme sur VM avec EBS, quel scheduler choisir ?

pour les environnements virtuels comme aws ebs où le backend de stockage est déjà optimisé par l'hyperviseur le scheduler noop est souvent le meilleur choix car il ne fait rien de plus et laisse l'hyperviseur gérer la réorganisation des i/o

noop c'est pas mal mais si t'es sur un kernel un peu plus récent (genre 5.x) le mq-deadline (multi-queue deadline) est aussi très efficace pour les nvme c'est un bon compromis pour pas mal de workloads car il gère mieux les priorités en lecture/écriture

avant de toucher au scheduler t'es sûr que c'est pas le burst balance de tes gp3 qui est à zéro ? si tu as tapé dans tes iops max pendant trop longtemps tes volumes peuvent être throttlés par aws et aucun scheduler ne pourra te sauver

# check cloudwatch metrics pour le burst balance

et ton workload c'est quoi plus de lecture ou d'écriture des petites i/o random ou des grosses i/o séquentielles pour des bases de données genre rds ou des fichiers logs ? ça peut changer pas mal la donne pour le choix du scheduler

aussi check tes mount options surtout le noatime ou relatime ça peut réduire les écritures inutiles sur les métadonnées et soulager l'i/o et le fstab bien sûr

ok je retiens noop et mq-deadline. pour le burst balance j'ai checké c'est ok. le workload c'est majoritairement de la petite écriture random type logs et des lectures occasionnelles. les mount options sont déjà ok

je vais tester mq-deadline d'abord puis noop pour voir la différence sur iostat. merci pour les tips ça éclaire ma lanterne