Des ingénieurs d’AWS signalent que les performances de PostgreSQL chutent de moitié sur Linux 7.0 — une correction pourrait ne pas être simple

• Une grave régression de performances a été découverte par des ingénieurs d’Amazon/AWS sur le noyau de développement Linux 7.0 : le serveur de base de données PostgreSQL voit son débit tomber à environ la moitié de celui observé avec le noyau précédent
• Mesuré sur des serveurs Graviton4, Linux 7.0 n’offre qu’environ 0,51x le débit du noyau précédent, la cause étant identifiée comme un temps bien plus important passé dans les spinlocks en espace utilisateur
• L’origine de la régression est un changement introduit dans Linux 7.0 concernant la restriction du mode de préemption du noyau ; un patch rétablissant PREEMPT_NONE comme valeur par défaut a été soumis, mais ses chances d’adoption restent incertaines
• L’auteur initial, Peter Zijlstra, estime qu’au lieu de modifier le noyau, il faudrait adapter PostgreSQL pour exploiter l’extension de tranche de temps de RSEQ (Restartable Sequences)
• La version stable de Linux 7.0 est attendue dans environ deux semaines et doit aussi servir de noyau de base à Ubuntu 26.04 LTS, ce qui fait craindre une dégradation de performances à grande échelle jusqu’à l’adaptation de PostgreSQL

---

Découverte du problème et ampleur

• L’ingénieur Amazon/AWS Salvatore Dipietro a signalé une régression du débit et de la latence de PostgreSQL
• Sur la base de mesures effectuées sur des serveurs Graviton4, Linux 7.0 ne fournit que 0,51x le débit du noyau existant
  • La cause a été identifiée comme un temps nettement plus important passé dans les spinlocks en espace utilisateur

Cause de la régression : restriction du mode de préemption

• Après bisect, le changement responsable a été identifié : la limitation du mode de préemption du noyau dans Linux 7.0
• Ce changement, intégré dans le cadre des mises à jour de l’ordonnanceur de Linux 7.0, a été mis en place pour les architectures CPU récentes en ne conservant que les modes de préemption Full et Lazy

Patch soumis et réaction des mainteneurs du noyau

• Un patch rétablissant PREEMPT_NONE comme mode de préemption par défaut a été soumis sur la mailing list du noyau Linux en raison de la gravité de la régression
• Cependant, Peter Zijlstra, auteur du code d’origine, s’oppose à l’acceptation de ce patch et affirme que la solution consiste à ce que PostgreSQL exploite l’extension de tranche de temps de RSEQ (Restartable Sequences)
  • L’extension de tranche de temps RSEQ est elle aussi une fonctionnalité incluse dans Linux 7.0
  • Zijlstra explique que « cela permet de limiter l’exposition à la préemption du détenteur du verrou »

Portée de l’impact et calendrier de sortie

• Si cette position est maintenue, les performances de PostgreSQL pourraient fortement se dégrader dans certains scénarios sur la version stable de Linux 7.0 tant que PostgreSQL n’aura pas été mis à jour
• La version stable de Linux 7.0 est attendue dans environ deux semaines
• Linux 7.0 doit servir de noyau de base d’Ubuntu 26.04 LTS, dont la sortie est prévue fin avril, ce qui laisse penser qu’Ubuntu 26.04 LTS pourrait subir le même impact

[unstabler]

J’ai entendu dire que des développeurs du kernel répètent depuis près de 10 à 20 ans aux développeurs de PostgreSQL que « les spinlocks en espace utilisateur ne sont pas recommandés, donc il vaudrait mieux reconsidérer cela »...

https://x.com/kosaki55tea/status/2040458791536497035

[GN⁺]

Commentaires sur Hacker News

• Cela vaut la peine de lire le message de suivi sur LKML du développeur de Postgres Andres Freund

  • Si le problème de performance est une régression reproductible, il est étrange que la seule solution soit de désactiver une fonctionnalité ajoutée dans la 7.0
  • Il ne faut pas s’arrêter à un seul message : en suivant l’ensemble du fil, on trouve davantage d’informations
  • Ce n’est pas une bonne idée de forcer une fonctionnalité bas niveau introduite en 7.0 pour corriger une régression qui n’apparaît qu’en 7.0
    Selon cet avis, les mainteneurs de Linux devraient faire du support des applications critiques comme PostgreSQL une priorité
    Cela rappelle l’époque où Fedora bloquait les mises à jour lorsqu’on installait Wine
  • La solution consistant à « utiliser les hugepages » revient systématiquement, mais la plupart des utilisateurs l’ignorent
  • La baisse de performance à 0,51x n’a été observée que sur une machine ARM64 à 96 cœurs, et n’a pas été reproduite sur AMD64
    Autrement dit, ce n’est pas un problème que rencontreront tous les utilisateurs de PostgreSQL en passant au dernier kernel

• Certains estiment qu’utiliser des spinlock en espace utilisateur sans support du kernel revient à s’exposer soi-même à une baisse de performance

  • Moi aussi, je n’aime pas l’usage des spinlock dans Postgres et je les supprime progressivement
    Mais les verrous basés sur futex provoquent une régression de performance à cause de l’augmentation des barrières mémoire
    En outre, Postgres doit encore prendre en compte des plateformes qui ne prennent pas en charge les opérations atomiques sur 8 octets, ce qui complique le remplacement
    Le spinlock en question a récemment été supprimé, et avec les huge pages, le goulet d’étranglement disparaît presque
  • Utiliser des spinlock en espace utilisateur a été comparé au fait de « se frapper soi-même au visage avec un marteau »
  • Certains estiment aussi que PostgreSQL a conservé les spinlock pour rester compatible avec d’anciens kernels, mais qu’il est temps d’arrêter

• Il y avait aussi l’affirmation selon laquelle « personne n’utilise le dernier kernel en production »
  En réalité, Ubuntu 26.04 LTS va bientôt sortir sur la base de Linux 7.0, donc beaucoup d’utilisateurs vont s’y retrouver rapidement
  Le problème est qu’à l’heure actuelle, il faut un patch kernel et non un simple réglage sysctl

  • Cela dit, il faut bien que certaines personnes testent les kernels récents pour repérer ce genre de problème en amont
  • Si PostgreSQL est touché, d’autres applications peuvent l’être aussi
  • Il a aussi été souligné que dans un environnement Docker, on partage le kernel de l’hôte, donc il n’y a pas vraiment de choix
  • À noter que l’option PREEMPT_NONE a été supprimée sur la plupart des plateformes

• Le contexte autour de PREEMPT_LAZY est expliqué dans un article de LWN

• Un commentaire plaisantait en demandant si quelqu’un avait vérifié si Jia Tan avait récemment soumis un patch kernel,
  ce à quoi une réponse disait qu’il n’y avait même pas besoin : il y a déjà assez de vulnérabilités comme ça

• Certains se demandaient si les optimisations d’I/O asynchrones et de requêtes parallèles de PostgreSQL 18 pourraient compenser cette baisse de performance
  Des détails sont disponibles dans les notes de version de PostgreSQL 18

• Certains s’interrogeaient aussi sur l’intérêt de modes de préemption dynamiques comme PREEMPT_LAZY
  L’avantage concret pour l’utilisateur moyen ne leur paraît pas évident

  • En réponse, il a été expliqué que c’est conçu pour augmenter le débit sans dégrader la latence
    Le kernel peut ainsi recevoir des informations plus explicites pour améliorer ses décisions d’ordonnancement

• Quelqu’un a commenté avoir mesuré une baisse de performance de 10 % entre FreeBSD 14 et 15.0, et s’est senti un peu consolé en voyant ce cas-ci

  • La réponse qui a suivi demandait : « au moins, est-ce qu’il y a eu autant de nouvelles fonctionnalités ? »

• Phoronix a aussi été critiqué pour avoir publié un article sans vérification suffisante
  Le mail de suivi concluait que le benchmark lui-même était erroné et qu’en réalité, le problème n’était pas si grave

  • Toutefois, la régression ne se produit que lorsque les huge pages ne sont pas utilisées
    Ce ne sera probablement pas un gros problème pour PostgreSQL, mais cela pourrait affecter d’autres applications qui ne peuvent pas utiliser les huge pages
    Donc, selon cet avis, ce n’est pas quelque chose qu’on peut simplement ignorer

• Un ancien lien vers un fil LKML a également été partagé