Choix du scheduler I/O pour RDS PostgreSQL sur Linux

Posté par roger-marcelle le 06/03/2026
RÉSOLU

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 ?


# Exemple de ce qu'on peut voir avec les outils du kernel
cat /sys/block/nvme0n1/queue/scheduler
# [mq-deadline] kyber none

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.

Commentaires

alphonse38

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.

mlegros

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.

alphonse38

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.

roger-marcelle

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 ?

mlegros

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.

alphonse38

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.

roger-marcelle

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

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire