Suite au Tuning Linux du mois dernier pour une faible latence PostgreSQL, il y a maintenant eu une pile géante de tests effectués sur deux systèmes de fichiers, trois correctifs et deux ensembles de paramètres de réglage du noyau exécutés. Le résultat jusqu'à présent est de nouvelles données intéressantes, et une autre amélioration engagée dans ce domaine qui se trouve maintenant dans PostgreSQL 9.1 (ce qui fait trois au total, les deux autres surveillent les correctifs). Je parlerai de la pratique recommandée le mois prochain lors d'une de mes conférences à PostgreSQL East, et j'ai également soumis quelque chose dans ce domaine pour le PGCon de mai. Ici, je vais aussi parler un peu plus des impasses, tant que ces souvenirs sont encore frais.
Le problème de base ici est que la façon dont PostgreSQL utilise le cache du système d'exploitation lors de l'écriture permet à de grandes quantités de données de s'accumuler. Lorsque les points de contrôle de la base de données se terminent, il peut en résulter de longs délais d'attente pour l'écriture de ces données. Il s'avère que le programme pgbench fourni avec PostgreSQL est vraiment bon pour créer ce problème, c'est donc ce que j'ai utilisé pour tous les tests. Les questions sur les moyens auxquelles j'ai voulu répondre étaient :
- Le remplacement de l'ancien système de fichiers ext3 améliore-t-il vraiment les performances des tâches de base de données ? J'ai écrit quelque chose sur le retour de XFS sur Linux l'année dernière qui montrait une belle amélioration par rapport à des benchmarks simples. Cependant, cela ne se traduit pas toujours par des améliorations de la base de données.
- Les récents réglages Linux dirty_bytes et dirty_background_bytes améliorent-ils vraiment la latence dans le pire des cas ?
- Laquelle des modifications de base de données suggérées pour améliorer le comportement ici fonctionne réellement ?
Vous pouvez voir tous les résultats des tests si vous souhaitez consulter les données brutes. Ce qui a été modifié pour chaque jeu de test est documenté, et si vous explorez un test individuel, vous pouvez voir les paramètres de base de données utilisés et d'autres informations de base sur le système d'exploitation. Cette page Web est ce qui ressort de mon programme de test pgbench-tools, si vous souhaitez essayer ce genre de chose vous-même.
Les résultats n'étaient pas très surprenants, mais ils étaient intéressants. Tous les tests ici ont été effectués avec deux tailles de base de données. À une taille de base de données plus petite (échelle =500, environ une base de données de 8 Go qui tient facilement dans les 16 Go de RAM du serveur), ext3 gérait 690 transactions/seconde, alors qu'à deux fois cette taille (échelle =1000, environ une base de données de 16 Go), c'était beaucoup plus chercher lié et seulement géré 349 TPS. XFS a augmenté ces deux nombres à 1757 TPS et 417 TPS, soit un gain de 255 % et 19 %, respectivement. Mieux encore, la latence dans le pire des cas pour une seule transaction est passée de 34 à 56 secondes (!) à 2 à 5 secondes. Bien que même 5 secondes ne soient pas géniales, il s'agit d'une charge de travail synthétique conçue pour rendre ce problème vraiment grave. Les nombres ext3 sont si terribles que vous risquez toujours de rencontrer un problème désagréable ici, même si je voyais en fait un meilleur comportement sur ce système de fichiers que dans les noyaux précédents (cela a été fait avec 2.6.32). /P>
Round 1 : XFS remporte une victoire écrasante. Je ne peux pas recommander ext3 comme système de fichiers viable sur les systèmes Linux avec beaucoup de mémoire si vous prévoyez d'écrire beaucoup; cela ne fonctionne tout simplement pas dans ce contexte. Ce serveur n'avait que 16 Go de RAM, vous pouvez donc imaginer à quel point ce problème est grave sur un serveur de production sérieux ici en 2011.
Ensuite, les réglages dirty_bytes et dirty_background_bytes. Ces deux-là ont pas mal amélioré la latence sur ext3, au prix de quelques ralentissements. Le pire de ceux-ci, le temps de maintenance ralenti en exécutant VACUUM, vous ne le voyez pas dans les résultats des tests eux-mêmes ; J'en ai déjà parlé dans ma précédente entrée de blog. Sur XFS, régler ces paramètres vers le bas est un désastre en termes de performances. À l'échelle de la base de données plus petite, les performances du TPS chutent de 46 % et, en plus, la latence s'aggrave.
Round 2 : Ne vous attendez pas à des miracles de dirty_bytes ou dirty_background_bytes. Ils semblent avoir un effet positif dans certaines circonstances, mais l'inconvénient potentiel est également important. Assurez-vous de tester soigneusement et d'inclure VACUUM dans vos tests avant d'ajuster ces deux éléments à la baisse.
Ensuite, j'ai fini par évaluer trois idées de correctifs pour PostgreSQL dans le cadre de ce dernier CommitFest :
- Répartir les appels de synchronisation des points de contrôle sur le disque (fsync) au fil du temps. Nous avions vu un certain succès avec cela sur un serveur client occupé lorsqu'il était combiné avec une meilleure gestion de la façon dont les autres opérations de synchronisation étaient mises en cache par la base de données
- Requêtes fsync compactes. Cette idée est dérivée de la première et s'est transformée en un patch écrit par Robert Haas. L'idée est que les clients essayant de synchroniser des données sur le disque pourraient être en concurrence avec l'écriture de points de contrôle. Le correctif permet aux clients de nettoyer la file d'attente des requêtes fsync s'ils la trouvent pleine.
- Trier les écritures au point de contrôle. Le concept est que si vous écrivez les choses dans l'ordre où la base de données pense que les choses sont stockées sur le disque, le système d'exploitation peut écrire plus efficacement. Ce correctif est apparu il y a quelques années avec des résultats de référence suggérant qu'il fonctionnait, mais à l'époque, personne n'était en mesure de reproduire les améliorations. L'idée s'intégrait suffisamment bien dans le reste du travail pour que je l'évalue à nouveau.
Round 3 : Après des semaines d'essais de tout cela, la seule approche de cet ensemble qui a montré l'amélioration à presque toutes les tailles de charge de travail était celle du compactage fsync. Le code de synchronisation du point de contrôle de propagation d'origine a aidé certains dans ce domaine, mais l'implémentation spécifique qui est maintenant validée pour 9.1 a fonctionné encore mieux. C'était un gain presque général de 10% sur la plupart des tests lourds en écriture que j'ai exécutés. C'est une grande amélioration pour PostgreSQL 9.1, et cela devrait complètement éliminer un problème que nous avons vu provoquer un ralentissement beaucoup plus important sur les systèmes de production ici.
Le reste des idées ici n'a pas reçu une évaluation aussi positive après de lourdes benchmarking, donc pour l'instant ceux-ci retournent sur l'étagère. Je vais continuer à collecter des données ici – certains tests ext4 sont la prochaine chose logique à essayer – puis je reviendrai au développement. Obtenir un gain de 10 % sur certaines charges de travail difficiles est certainement agréable, mais il y a encore beaucoup trop de comportements dans le pire des cas ici pour considérer les problèmes de synchronisation des points de contrôle comme un sujet clos.
