postgres perf dégueu sous kernel récent io_uring suspect

rgrenier 06/12/2025
RÉSOLU
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

salut tout le monde. j'ai upgrade notre vm postgre sur un kernel linux plus récent et la perf est catastrophique. les requêtes qui prenaient quelques ms prennent des centaines. j'ai checké l'iops la cpu tout est ok. je me demande si c pas io_uring ou un truc dans le sched du noyau

EXPLAIN ANALYZE SELECT * FROM big_table WHERE creation_date < NOW() - INTERVAL '1 month' ORDER BY id DESC LIMIT 100;
06/12/2025 à 01:34

18 commentaires

kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

hmm kernel récent c'est quel version ? et postgres aussi. y a eu pas mal de changements sur l'implémentation io_uring et son interaction avec le page cache et les schedulers. t'as vérifié le scheduler disque utilisé

06/12/2025 à 22:47
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

kernel 5.15 vers 6.6. postgres 14. le scheduler est cfq sur les deux. j'ai pas touché

07/12/2025 à 18:22
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

cfq est déprécié depuis longtemps non ? passe à mq-deadline ou none pour nvme. et cfq peut avoir des soucis avec des workloads mixtes read/write asynchrones qui profiteraient d'io_uring

08/12/2025 à 12:44
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

ah oui merde j'ai pas checké les defaults. ok je tente mq-deadline

09/12/2025 à 10:43
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

et aussi postgre utilise posix_fadvise pour optimiser le cache. avec io_uring y a des interactions différentes. t'as quoi dans ton postgresql.conf pour effective_io_concurrency et wal_compression

10/12/2025 à 09:52
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

effective_io_concurrency = 1 et wal_compression = off

11/12/2025 à 04:28
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

ok effective_io_concurrency à 1 c'est pas bon pour les ssd nvme qui peuvent gérer beaucoup plus d'iops concurrentes. essaie de le monter à 100 ou 200. et wal compression on ça aide à réduire les écritures disque

11/12/2025 à 23:23
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

j'ai mis mq-deadline. ça a un peu aidé mais c'est pas encore ça. je vais monter effective_io_concurrency et wal_compression

12/12/2025 à 19:10
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

si tu utilises beaucoup d'io_uring pour autre chose sur cette machine ça peut rentrer en conflit avec postgres. t'as d'autres applis gourmandes en io sur ce serveur qui feraient des appels système asynchrones

13/12/2025 à 15:38
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

non c'est un serveur dédié postgre. rien d'autre d'important

14/12/2025 à 09:51
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

y a eu des bugs avec io_uring et certaines versions de libaio ou glibc. assure-toi que tes libs système sont à jour. et est-ce que ton postgres utilise bien o_direct pour certains segments ou tout passe par le cache du système d'exploitation

15/12/2025 à 04:39
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

je crois que c'est le default donc pas de O_DIRECT explicite. juste le cache OS. les libs sont à jour je viens de faire un apt update && apt upgrade

15/12/2025 à 23:42
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

ça peut être ton fs.aio-max-nr aussi. le max nombre d'opérations aio en attente. si c'est trop bas ça bloque. check cat /proc/sys/fs/aio-max-nr

16/12/2025 à 23:05
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

c'est à 65536. je pense que c'est assez haut

17/12/2025 à 20:02
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

ok alors. t'as testé avec synchronous_commit = off pour voir si c'est les écritures du wal qui te ralentissent de ouf ? juste pour un test pas en prod

18/12/2025 à 14:21
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

oui j'ai testé en dev ça améliore beaucoup. donc c'est bien l'écriture disque. avec les nouvelles options de mount et effective_io_concurrency à 200 et wal_compression à on c'est beaucoup mieux. j'ai retrouvé des perfs comparables. merci mec !

19/12/2025 à 09:48
kpineau
Membre Actif Secouriste
Avatar de kpineau
kpineau
Membre Actif Secouriste

nickel ! souvent c'est le combo kernel + config postgres + fs options qui peut te tuer les perfs sur les workloads i/o bound

20/12/2025 à 05:55
rgrenier
Auteur Actif
Avatar de rgrenier
rgrenier
Auteur Actif

grave c'était exactement ça. un grand merci tu m'as évité des heures de galère

21/12/2025 à 03:23

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