6 commentaires
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
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
Laisser une réponse
Vous devez être connecté pour poster un message !
yo les pros du noyau j'ai un souci de perf i/o sur une vm linux qui tourne avec des volumes ebs sur aws l'
iowaitest souvent au-dessus de 50% et ça plombe l'appli les volumes sont desgp3j'ai testé
cfqdeadlineetnoopmais je vois pas de différence significative des idées sur le meilleur scheduler pour ce genre de setup