L'équipe en charge du développement de PostgreSQL réétudie son modèle basé sur les processus et la possibilité de passer à un modèle basé sur les threads. Cette transition présente des avantages potentiels en termes de performances et d'améliorations, mais elle soulève également des inquiétudes quant aux coûts, à la complexité et à la perte d'isolation. Le projet explore les défis techniques liés à cette transition, tels que la gestion des variables globales et la compatibilité des extensions. Cependant, le consensus et l'engagement nécessaires pour réaliser ce changement ne sont pas encore clairs dans la communauté PostgreSQL.Un rappel sur le modèle basé sur les processus de PostgreSQL
Le modèle basé sur les processus est un système dans lequel chaque instance de PostgreSQL s'exécute en tant qu'ensemble de processus coopérants. Chaque client connecté au serveur est géré par un processus distinct, et ces processus communiquent entre eux via des régions de mémoire partagée à l'aide d'une bibliothèque élaborée.
Ce modèle a été utilisé avec succès pendant de nombreuses années grâce aux avantages qu'il offre, notamment :
- L'isolation : chaque client est exécuté dans un processus séparé, ce qui offre une isolation naturelle entre les différentes connexions. Cela garantit que les transactions d'un client ne peuvent pas interférer avec celles d'un autre client.
- La robustesse : la séparation des clients en processus distincts assure une meilleure résistance aux pannes. Si un processus échoue, les autres processus continuent de fonctionner normalement.
- La sécurité : l'isolation entre les processus contribue à renforcer la sécurité du système en empêchant l'accès non autorisé aux données d'un client par un autre client.
Toutefois, le modèle basé sur les processus de PostgreSQL présente également quelques limites qui deviennent de plus en plus harassantes pour de nombreux développeurs. Elles peuvent être observées à différents niveaux :
- Coûts en termes de performances : les changements de contexte entre les processus sont plus coûteux que les changements de threads dans le même processus. Cela peut entraîner une surcharge significative, en particulier sur des machines de grande taille ou lorsque le nombre de connexions simultanées est élevé.
- Consommation de ressources : chaque processus nécessite une allocation de mémoire et d'autres ressources du système d'exploitation, ce qui peut devenir problématique lorsque de nombreuses connexions sont actives. Cela limite la capacité de PostgreSQL à évoluer efficacement sur des systèmes de grande taille.
- Complexité du développement : le modèle basé sur les processus nécessite une gestion complexe des communications et de la synchronisation entre les processus. Cela peut entraîner une duplication de code et une complexité supplémentaire dans le développement et la maintenance du système.
En résumé, le modèle basé sur les processus de PostgreSQL offre une isolation et une robustesse importantes, mais il présente des coûts en termes de performances, de consommation de ressources et de complexité du développement. Ces limites conduisent aujourd'hui les développeurs de PostgreSQL à réévaluer le modèle et à envisager une transition vers un modèle basé sur les threads, afin de résoudre ces problèmes potentiels et d'améliorer les performances et l'évolutivité du système.
Proposition de passage à un modèle basé sur les threads
L'idée de passer à un modèle basé sur les threads est venue de Heikki Linnakangas, contributeur PostgreSQL et co-fondateur de Neon, une implémentation serverless de PostgreSQL en open source.
« Je pense qu'il y a maintenant un consensus assez solide pour dire que ce serait une bonne chose, plus qu'auparavant » de migrer PostgreSQL vers un modèle basé sur les threads, dit-il dans une proposition envoyée au groupe pgsql-hackers le 5 juin dernier. Il y a « beaucoup de travail à accomplir et de nombreux détails à régler, mais aucune objection à l'idée dans les grandes lignes. Le but de cet e-mail est de rendre ce consensus silencieux explicite », a-t-il écrit.
Reconnaissant les défis auxquels il va falloir faire face, dans son message, il ne manque pas de donner une idée de ce qu'implique d'entamer un tel changement.
Il semble toutefois que le co-fondateur de Neon a dit tout haut ce que beaucoup pensaient tout bas. Andres Freund, contributeur, développeur et committer PostgreSQL aborde le sujet en allant dans le même sens : « Je pense que nous commençons à atteindre plusieurs limites liées au modèle basé sur les processus, notamment sur des machines plus grandes. La surcharge des changements de contexte inter-processus est intrinsèquement plus élevée que les changements de threads dans le même processus - et ma suspicion est que cette surcharge continuera d'augmenter. Lorsque vous avez un nombre important de connexions, nous passons énormément de temps dans les TLB miss, et c'est inhérent au modèle de processus, car vous ne pouvez pas partager le TLB entre les processus. »
Précisons qu'un TLB miss (Translation Lookaside Buffer miss) se produit lorsqu'une adresse virtuelle n'est pas trouvée dans le TLB, une structure de données utilisée pour traduire les adresses virtuelles en adresses physiques. Lorsque cela se produit, le processeur doit effectuer une recherche dans la table de pagination pour obtenir la traduction nécessaire. Cette recherche supplémentaire peut prendre plus de temps, ce qui entraîne un retard dans l'accès à la mémoire.
Andres Freund a également souligné que le modèle de processus impose des coûts en termes de développement, obligeant le projet à maintenir beaucoup de code dupliqué, y compris plusieurs mécanismes de gestion de la mémoire qui ne seraient pas nécessaires dans un seul espace d'adressage. Dans un message, il ajoute également qu'il serait possible de partager plus efficacement l'état entre les threads, car ils s'exécutent tous dans le même espace d'adressage.
Réactions de la communauté
Si les problèmes causés par le modèle basé sur les processus sont évidents pour tout le monde, les réactions à la suite de la proposition de passage au modèle basé sur les threads remettent en doute le consensus prétendu par Heikki Linnakangas. L'une des résistances enregistrées vient de Tom Lane, membre du comité de direction central de PostgreSQL :
« Je pense que cela sera un désastre. Il y a beaucoup trop de code qui ne va plus fonctionner », dit-il. Il estime que le coût de ce changement serait « énorme », que cela pourrait créer « plus d'un bogue de sécurité » et que les bénéfices d'un tel changement ne justifieraient pas le coût à supporter.
Allant dans le même sens que Tome Lane, Jonathan Katz, membre de l'équipe du projet PostgreSQL, estime pour sa part qu'il y a d'autres travaux qui devraient avoir une priorité plus élevée que le passage au modèle basé sur les threads.
Dans la communauté, d'autres développeurs encore ont exprimé leur inquiétude quant à la perte de l'isolation fournie par des processus séparés. Cette perte aura pour conséquence de rendre le système globalement moins robuste.
Entre les deux extrémités, de nombreux développeurs de PostgreSQL se montrent favorables à un tel changement tout en restant assez prudents sur les résultats attendus. C'est le cas de Robert Haas, committer et contributeur majeur au projet PostgreSQL qui estime que PostgreSQL ne s'adapte pas bien aux systèmes de plus grande taille, principalement en raison des ressources consommées par tous ces processus. « Ce ne sont pas toutes les bases de données qui ont ce problème, et PostgreSQL ne pourra pas en finir avec ce problème sans un changement architectural majeur », dit-il. Simplement passer aux threads ne serait peut-être pas suffisant, mais il pense que ce changement permettrait plusieurs autres améliorations.
Les défis du passage au modèle basé sur les threads
Que la proposition soit approuvée ou pas, la mise en œuvre présentera des défis qui pourraient mettre en jeu la survie de PostgreSQL dans un monde où il existe des alternatives open source tout aussi robustes.
L'un des défis liés à cette transition semble être l'utilisation « généralisée et souvent gratuite de variables globales » par le serveur PostgreSQL. Les variables globales fonctionnent assez bien lorsque chaque processus du serveur a son propre ensemble, mais cette approche ne marche pas lors de l'utilisation des threads. Et notons que PostgreSQL utilise actuellement environ 2000 de ces variables.
Des pistes de solutions ont été mises en avant pour la gestion des variables avec le modèle basé sur les threads. L'approche la plus facile et qui pourrait fonctionner consiste simplement à placer toutes les variables globales dans un stockage spécifique à chaque thread. Mais une utilisation intensive du stockage spécifique à chaque thread entraînerait une pénalité de performance, et donc réduirait les avantages du passage aux threads. En plus, le déplacement des variables globales vers le stockage spécifique à chaque thread n'est que la partie la plus facile du travail.
La refonte de postmaster, la définition de la manière de gérer les bibliothèques d'extension, la compatibilité des extensions, le développement d'outils rendant le développement d'un postgres à thread réalisable, la portabilité, sont entre autres d'autres défis bien plus difficiles, a averti Andres Freund.
En plus de tout cela, les développeurs de PostgreSQL pourraient être contraints de prendre en charge à la fois les modèles basés sur les processus et ceux basés sur les threads, peut-être indéfiniment. Robert Haas dit par exemple ne pas être convaincu qu'il serait un jour possible de supprimer la prise en charge du modèle basé sur les processus. Les threads pourraient en effet ne pas offrir de meilleures performances pour tous les cas d'utilisation, ou certaines extensions importantes pourraient ne jamais prendre en charge l'exécution en threads. Autrement dit, la suppression de la prise en charge du modèle basé sur les processus ne pourrait vraiment être envisagée que lorsque la solution des threads, si elle est implémentée, fonctionne bien. Et cette nécessité de continuer à prendre en charge l'exécution dans le mode basé sur les processus rendrait plus difficile la mise en œuvre de certains des avantages offerts par les threads et augmenterait considérablement la charge de maintenance dans l'ensemble.
Les défis d'un tel changement sont donc énormes pour l'avenir de PostgreSQL. Dans un monde open source en constante évolution, où des projets peuvent apparaître et disparaître rapidement, PostgreSQL a pu se faire une place. Mais apporter des changements fondamentaux à une base de code aussi ancienne n'est jamais une tâche facile. Si le processus se déroule bien, tout le monde y gagnera même si certaines fonctionnalités importantes seront sacrifiées d'office. Mais la moindre erreur peut avoir un impact important sur PostgreSQL et son écosystème. Tout changement de cette envergure est donc à étudier sérieusement.
Source : Proposition de passage à un modèle basé sur les threads
Et vous ?
Que pensez-vous de cette proposition ? Pour les bénéfices attendus, cela vaut-il la peine d'effectuer un tel changement ?Voir aussi :
PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle base de données PostgreSQL, il permet de contourner les ORM IvorySQL : un PostgreSQL open source compatible avec Oracle pourrait répondre au besoin de migrer des applications Oracle vers l'open source Postgres PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire et sur disque, et apporte la populaire commande MERGE La majorité des serveurs PostgreSQL sur Internet ne seraient pas sécurisés, selon Jonathan Mortensen, alors qu'il est souvent considéré comme un système plus fiable et plus robuste que MySQL