Membre depuis le 10/04/2019
yo. si c'est du nvme, et que c'est une vm aws, le noop est souvent le best choice. le scheduler hardware (celui de l'nvme) est déjà super optimisé. rajouter un scheduler logiciel par dessus c'est souvent de l'overhead inutile.
Membre depuis le 20/05/2020
d'acc avec 2. le mq-deadline peut être ok mais le noop laisse la carte nvme gérer la prio. pour du rds c'est encore plus vrai parce que t'es sur du bloc device virtualisé. le kernel n'a pas une vue complète de l'infra i/o sous-jacente.
Membre depuis le 10/04/2019
faut aussi voir si t'as des contraintes de fairness entre plusieurs workloads sur la même instance. mais pour une db dédiée, max perf brute c'est noop.
Membre depuis le 31/03/2019
on est sur une instance dédiée à la db pas de partage. je suis surpris par le noop j'aurais pensé qu'il fallait un scheduler intelligent. vous avez des benchs ou des retours d'xp là dessus ?
Membre depuis le 20/05/2020
le truc c'est que les schedulers comme mq-deadline ou cfq sont faits pour réordonner les opérations pour minimiser les mouvements de tête sur un disque rotatif. sur du nvme qui est super rapide et parallèle, et surtout virtuel dans le cloud, cette optimisation devient contre-productive. le noop passe juste l'io direct au device. y'a plein de doc sur redhat ou intel pour le noop sur nvme.
Membre depuis le 10/04/2019
exact. pour du disque physique rotatif (vieux hdd) cfq était bien. pour du ssd local deadline ou bfq sont pas mal. pour du nvme ou du bloc virtuel comme ebs/rds c'est presque toujours noop. le kernel linux ne peut pas savoir que derrière ton nvme y'a un réseau et des arrays de ssd gérés par aws. autant le laisser envoyer la patate direct.
Membre depuis le 31/03/2019
ok je vois le point. ça fait sens. je vais voir comment on peut modifier ça sur rds mais je pense que c'est faisable via le paramètre group. je vous tiens au jus des perfs
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
roger-marcelle
Membre depuis le 31/03/2019
Salut la commu ! On a un souci de perfs avec notre RDS PostgreSQL qui tourne sur des instances Linux (derrière l'abstraction AWS bien sûr). Les latences I/O sont super variables et on suspecte le scheduler I/O sous-jacent. Je sais qu'AWS gère ça mais on a le droit de spécifier certains flags. C'est quoi le meilleur pour du PostgreSQL avec pas mal d'écritures aléatoires et des lectures sequentielles lourdes ?
On est actuellement sur mq-deadline par défaut. On devrait bouger sur kyber ou cfq ou noop ? Sachant que c'est du NVMe derrière.