Je maintiens un certain nombre de projets dont le but dans la vie est de faciliter les tests de parties de PostgreSQL. Tous ces éléments ont reçu une mise à niveau décente au cours de la semaine dernière.
la mise à l'échelle du flux teste l'augmentation de la vitesse de la mémoire sur les serveurs à mesure que davantage de cœurs sont mis en jeu. Ce sont des données fascinantes, en quantité suffisante pour commencer à voir de vraies tendances. Il fonctionne désormais correctement sur les systèmes avec de grandes quantités de cache CPU, car ils ont de nombreux cœurs. Il était possible auparavant qu'il soit si agressif avec le dimensionnement de l'ensemble de test pour éviter l'impact sur le cache qu'il utilisait plus de mémoire que ce qui pouvait être alloué avec la conception actuelle du code de flux. Cela a été réduit. Si vous avez un serveur à 48 cœurs ou plus, je pourrais tester davantage ce nouveau code pour voir si la nouvelle façon dont je gère cela a du sens.
peg est un script que j'ai écrit pour faciliter la construction de PostgreSQL à partir des sources, généralement pour le travail de développeur ou pour essayer temporairement une version plus récente sur un système de production. Il était très facile de se confondre avec le basculement entre les projets et leurs branches git associées auparavant; la documentation dans ce domaine est bien améliorée.
pgbench-tools est ma maison de travail de test de performance, vous permettant de mettre en file d'attente des jours de référence et d'avoir suffisamment d'outils d'analyse disponibles pour y donner un sens. Le programme suit désormais le paramètre pg_stat_bgwriter.buffers_backend_fsync récemment introduit si vous avez une version qui le prend en charge (actuellement uniquement une version récente de soure, ce qui nous ramène à l'utilité de peg). Vous pouvez également lui dire d'exécuter chaque test pendant une durée fixe, ce qui facilite grandement les tests à des valeurs client/taille extrêmement variables.
En ce qui concerne ce que vous pouvez faire avec pgbench-tools… à partir d'aujourd'hui, je partage maintenant les tests de benchmarking que je fais sur PostgreSQL 9.1 sur le serveur le plus puissant dont j'ai une utilisation illimitée. 8 cœurs, 16 Go de RAM, 3 disques de base de données RAID-0, 1 volume de disque WAL, cache sauvegardé par batterie Areca. Vous pouvez voir les résultats. Les exécutions sont organisées en ensembles de tests, chacun représentant une sorte de modification de la configuration. Par exemple, #1 dans ces données n'exécute que SELECT, #2 exécute TPC-B mais avec 8 Go de RAM et un code plus ancien, tandis que le truc chaud est #3, exécutant TPC-B avec 16 Go de RAM et un code qui suit buffers_backend_fsyncs.
Il existe plusieurs correctifs dans la file d'attente PostgreSQL 9.1 liés aux performances dans les domaines mis en évidence par ces résultats - que Linux peut avoir une latence extrêmement élevée dans le pire des cas sur les charges de base de données lourdes en écriture. Un bon exemple moyen est le test 215 : échelle de 1 000, 32 clients, 365 TPS., Mais la latence dans le pire des cas est de 43 secondes, et vous pouvez voir les points morts dans le graphique TPS. C'est tout simplement terrible, et il y a quelques concepts qui circulent pour savoir comment faire exactement cela.
Si quelqu'un lit ceci a un serveur puissant disponible pendant quelques semaines pour exécuter des tests comme celui-ci, je serais heureux de vous aider à reproduire cet environnement et de voir quel type de résultats vous voyez. La seule magie que j'ai est de m'entraîner à définir la mise à l'échelle et les charges du client afin de ne pas perdre beaucoup de temps avec des tests improductifs. Le reste de mon processus est entièrement gratuit et documenté.
