Aujourd'hui est la date limite pour le tarif spécial de la chambre à l'hôtel qui accueille la PostgreSQL Conference East 2010 ce mois-ci. Si vous avez tergiversé en réservant une place à la conférence, cela commencera à vous coûter à partir de demain.
Mon exposé porte sur l'analyse comparative du matériel de base de données et est prévu en fin d'après-midi le premier jour, le jeudi 25 mars. Ceux qui ont peut-être déjà vu cette conférence, soit en direct à PGCon 2009, soit via le lien vidéo disponible là-bas, se demandent peut-être si je vais faire glisser les mêmes diapositives et parler à nouveau. Pas le cas; bien que la philosophie générale de la conférence ("ne faites confiance à personne, exécutez vos propres tests") reste la même, les exemples et le mélange de tests suggérés ont été mis à jour pour refléter une autre année d'avancées matérielles, de travail sur PostgreSQL et mes propres recherches au cours de cette temps. La situation entre Intel et AMD en particulier a beaucoup changé, nécessitant un nouvel ensemble de références de mémoire pour vraiment suivre ce qui se passe actuellement.
Et PostgreSQL 9.0 a résolu un problème majeur qui l'empêchait de fournir normalement des résultats précis sous Linux, en raison d'une régression du noyau qui a aggravé une situation déjà bien trop courante : il est facile pour un seul client pgbench de devenir le goulot d'étranglement lors de son exécution, plutôt que la base de données elle-même. L'examen que j'ai fait pour pgbench multi-thread (qui peut également être multi-processus pgbench sur les systèmes qui ne prennent pas en charge les threads) a suggéré une accélération solide> 30% même sur les systèmes qui n'avaient pas la mauvaise incompatibilité du noyau sur eux. Des tests ultérieurs suggèrent qu'il peut facilement prendre 8 processus pgbench pour obtenir un débit complet des processeurs modernes, même peu coûteux, sous les noyaux Linux récents. Je vais expliquer exactement comment cela se passe sur de tels systèmes et comment cette nouvelle fonctionnalité permet à nouveau d'utiliser pgbench comme principal moyen de mesurer les performances du processeur exécutant la base de données.
Récemment, j'ai également mis à jour le référentiel git pour pgbench-tools qui ajoute une prise en charge fonctionnelle de PostgreSQL 8.4 et de la compatibilité de base 9.0, et la prochaine mise à jour inclura la prise en charge de l'option multithread maintenant que j'ai cartographié comment cela a besoin de travailler. Tout cela mène quelque part. Une fois que nous avons des mesures précises des performances de PostgreSQL qui sont limitées par le processeur côté serveur, ce qui n'a pas souvent été le cas depuis plus de deux ans maintenant, celles-ci deviennent à nouveau un moyen utile de surveiller les régressions de performances dans la base de code PostgreSQL. Les tests inclus devront être étendus pour que cela couvre davantage, mais pour l'instant nous avons atteint un point où pgbench peut être utilisé pour trouver des régressions qui ont un impact sur la vitesse d'exécution des instructions SELECT simples. Je sais que cela fonctionne comme prévu, car chaque fois que je construis accidentellement PostgreSQL avec des assertions, c'est intercepté parce que je vois le taux de traitement moyen chuter de façon spectaculaire.
Une fois que j'ai installé quelques systèmes ici pour tester de telles régressions, la question est de savoir comment automatiser ce que je fais, puis faire la même chose avec un plus large éventail de vérifications de build. Idéalement, vous seriez en mesure de voir un graphique des performances moyennes de SELECT chaque jour, ventilées par version, de sorte que lorsqu'un commit qui le réduisait était introduit, il serait immédiatement évident lorsque les performances chuteraient. C'est l'objectif rêvé pour construire une ferme de performance similaire à la ferme de construction PostgreSQL. Les pièces sont presque toutes ensemble maintenant :mes parties pgbench sont en train de se terminer, les extensions de la ferme de construction pour la faire parler directement à git avancent (ce n'est pas une exigence, mais personne travaillant sur ce projet ne veut utiliser CVS si nous pouvons l'éviter) , et la principale chose qui manque à ce stade est quelqu'un à qui consacrer du temps pour intégrer ce que j'ai fait dans un client de type buildfarm.
Et il semble que nous ayons maintenant une entreprise commanditaire prête à aider avec cette partie du travail, dont je laisserai le crédit quand nous aurons tous terminé, et cela devrait se produire cet été. Je m'attends à ce que le développement de PostgreSQL 9.1 et le backpatching de 9.0 se produisent avec une batterie de performances précoce en place pour se prémunir contre les régressions de performances. Si nous pouvons rétroporter le nouveau pgbench multi-thread vers les anciennes versions de PostgreSQL, nous pourrions également les inclure dans le mélange. J'ai déjà un rétroportage du pgbench 8.3, qui a beaucoup d'améliorations, que je maintiens juste pour tester les systèmes 8.2. Avec pgbench en tant que module de contribution assez autonome, il est possible d'en créer un plus tard différent du reste du système, tant qu'il ne s'attend pas à ce que de nouvelles fonctionnalités de base de données existent également.
Si c'est quelque chose qui vous intéresse, mon discours à la conférence va tracer les fondations sur lesquelles je m'attends à ce qu'il soit construit. Quoi qu'il en soit, j'espère que vous pourrez vous rendre à la conférence et profiter de la longue liste de conférences qui y sont présentées.
