{"id":167524,"date":"2026-04-04T23:11:54","date_gmt":"2026-04-04T21:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-yadre-linux-7-0-vyyavili-regressiyu-v-dva-raza-snizhayushhuyu-proizvoditelnost-postgresql"},"modified":"2026-04-04T23:11:54","modified_gmt":"2026-04-04T21:11:54","slug":"v-yadre-linux-7-0-vyyavili-regressiyu-v-dva-raza-snizhayushhuyu-proizvoditelnost-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/v-yadre-linux-7-0-vyyavili-regressiyu-v-dva-raza-snizhayushhuyu-proizvoditelnost-postgresql","title":{"rendered":"Une r\u00e9gression a \u00e9t\u00e9 d\u00e9tect\u00e9e dans le noyau Linux 7.0, r\u00e9duisant de moiti\u00e9 les performances de PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Un ing\u00e9nieur d'Amazon a identifi\u00e9 une r\u00e9gression sp\u00e9cifique au noyau Linux 7.0, dont la sortie est pr\u00e9vue pour le 13 avril. Le changement des param\u00e8tres du planificateur de t\u00e2ches a entra\u00een\u00e9 une diminution significative de la bande passante et de la r\u00e9activit\u00e9 lors de l'utilisation de la base de donn\u00e9es PostgreSQL sur des syst\u00e8mes avec une architecture ARM64. Avec le noyau 7.0, les performances lors du test pgbench \u00ab simple-update \u00bb ont chut\u00e9 de pr\u00e8s de moiti\u00e9 \u2014 passant de 98565 \u00e0 50751. <\/p>\n
Le ralentissement est d\u00fb \u00e0 un changement du mode de pr\u00e9emption dans le planificateur par d\u00e9faut, passant de PREEMPT_NONE \u00e0 PREEMPT_LAZY sur les architectures qui supportent ce mode, ce qui a conduit PostgreSQL \u00e0 passer 55 % de son temps CPU \u00e0 appeler s_lock(). Pour rem\u00e9dier \u00e0 ce probl\u00e8me, il a \u00e9t\u00e9 propos\u00e9 de revenir au mode PREEMPT_NONE par d\u00e9faut et de lever son lien avec le param\u00e8tre ARCH_NO_PREEMPT. <\/p>\n
Peter Zijlstra, l'auteur des modifications ayant caus\u00e9 la r\u00e9gression et mainteneur du planificateur de t\u00e2ches ainsi que des sous-syst\u00e8mes de gestion des verrous du noyau, a d\u00e9clar\u00e9 qu'un correctif doit \u00eatre effectu\u00e9 dans le code de PostgreSQL. Pour rem\u00e9dier \u00e0 la baisse de performance, il a recommand\u00e9 d'utiliser l'extension r\u00e9cemment ajout\u00e9e au noyau \u00ab rseq slice \u00bb (Restartable Sequences) pour r\u00e9duire la probabilit\u00e9 de vice de la d\u00e9tention du verrou. <\/p>\n
Il n'est pas encore clair quelle solution adoptera Linus Torvalds, qui suit la r\u00e8gle selon laquelle le noyau ne doit pas d\u00e9grader les performances et casser la compatibilit\u00e9 avec l'espace utilisateur. D'une part, le noyau 7.0 est en phase finale de test avant sa sortie, et revenir sur les r\u00e9glages du planificateur pourrait entra\u00eener d'autres r\u00e9gressions. D'autre part, les utilisateurs pourraient faire face \u00e0 une baisse de performance par deux fois pour l'une des bases de donn\u00e9es les plus populaires. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"