Vandaag is de deadline voor de speciale kamerprijs in het hotel dat deze maand de PostgreSQL Conference East 2010 organiseert. Als je het boeken van een plek op de conferentie uitstelde, gaat dat je vanaf morgen kosten.
Mijn lezing gaat over Database Hardware Benchmarking en staat gepland voor laat in de middag op de eerste dag, donderdag 25 maart. Degenen die deze lezing misschien eerder hebben gezien, hetzij live op PGCon 2009 of via de videolink die daar beschikbaar is, vragen zich misschien af of ik dezelfde dia's naar voren ga slepen en nog een keer praten. Niet het geval; terwijl de algemene filosofie van het gesprek ("vertrouw niemand, voer je eigen benchmarks") hetzelfde blijft, zijn de voorgestelde voorbeelden en testmix bijgewerkt om weer een jaar aan hardware-vooruitgang, PostgreSQL-werk en mijn eigen onderzoek gedurende die tijd weer te geven tijd. Vooral de Intel vs. AMD-situatie is behoorlijk veranderd, waardoor een nieuwe set geheugenbenchmarks nodig is om echt te volgen wat er nu aan de hand is.
En PostgreSQL 9.0 loste een groot probleem op dat ervoor zorgde dat het normaal geen nauwkeurige resultaten opleverde op Linux, vanwege een kernelregressie die een al veel te vaak voorkomende situatie nog veel erger maakte:het is gemakkelijk voor een enkele pgbench-client om de bottleneck te worden bij het uitvoeren ervan, in plaats van dan de database zelf. De recensie die ik deed voor multi-threaded pgbench (wat ook multi-proces pgbench kan zijn op systemen die geen threads ondersteunen) suggereerde een solide>30% versnelling, zelfs op systemen die niet de slechte kernel-incompatibiliteit hadden. Daaropvolgende tests suggereren dat het gemakkelijk 8 pgbench-processen kan kosten om volledige doorvoer te krijgen van zelfs goedkope moderne processors onder recente Linux-kernels. Ik zal precies bespreken hoe dat uitpakt op dergelijke systemen en hoe deze nieuwe functie het weer mogelijk maakt om pgbench te gebruiken als de primaire manier om de CPU-prestaties van de database te meten.
Onlangs heb ik ook een update gemaakt van de git-repo voor pgbench-tools die werkondersteuning toevoegt voor PostgreSQL 8.4 en basis 9.0-compatibiliteit, en de volgende update zal ondersteuning bieden voor de multi-threaded optie nu ik in kaart heb gebracht hoe dat moet werken. Dit leidt allemaal ergens toe. Zodra we nauwkeurige metingen hebben voor PostgreSQL-prestaties die CPU-beperkt zijn aan de serverzijde, iets dat nu al meer dan twee jaar niet vaak het geval is, worden die opnieuw een handige manier om te controleren op prestatieregressies in de PostgreSQL-codebase. De meegeleverde tests zullen daarvoor moeten worden uitgebreid om uiteindelijk meer te dekken, maar voor nu hebben we een punt bereikt waarop pgbench kan worden gebruikt om regressies te vinden die van invloed zijn op hoe snel eenvoudige SELECT-instructies worden uitgevoerd. Ik weet dat dat werkt zoals verwacht, want elke keer dat ik per ongeluk PostgreSQL bouw met beweringen daarop, wordt dat opgemerkt omdat ik de gemiddelde verwerkingssnelheid dramatisch zie dalen.
Zodra ik hier een aantal systemen heb ingesteld om op dergelijke regressies te testen, wordt de vraag hoe ik kan automatiseren wat ik doe, en vervolgens hetzelfde te doen tegen een groter aantal build-checkouts. In het ideale geval zou je elke dag een grafiek kunnen zien van de gemiddelde SELECT-prestaties, opgesplitst per versie, zodat wanneer een commit die deze verminderde, werd geïntroduceerd, het meteen duidelijk zou zijn wanneer de prestaties daalden. Dit is het droomdoel voor het bouwen van een prestatiefarm vergelijkbaar met de PostgreSQL-buildfarm. De stukjes zijn nu bijna allemaal samen:mijn pgbench-onderdelen zijn ingepakt, uitbreidingen van de buildfarm om het rechtstreeks met git te laten spreken gaan mee (geen vereiste, maar niemand die aan dit project werkt, wil CVS gebruiken als we het kunnen vermijden) , en het belangrijkste dat op dit moment ontbreekt, is iemand om de tijd in te steken om wat ik heb gedaan te integreren in een buildfarm-achtige client.
En het lijkt erop dat we nu een bedrijfssponsor hebben die bereid is om te helpen met dat deel van het werk, aan wie ik de eer zal geven als we allemaal klaar zijn, en dat staat gepland voor deze zomer. Ik verwacht volledig dat de ontwikkeling van PostgreSQL 9.1 en backpatching van 9.0 zal plaatsvinden met een vroege prestatiefarm om te waken tegen achteruitgang van de prestaties. Als we de nieuwe multi-threaded pgbench kunnen terugzetten naar oudere PostgreSQL-versies, kunnen we ze ook in de mix opnemen. Ik heb al een backport van de 8.3 pgbench, die veel verbeteringen heeft, ik onderhoud alleen voor het testen van 8.2-systemen. Met pgbench als een redelijk zelfstandige bijdragemodule, is het mogelijk om een latere module te bouwen die verschilt van de rest van het systeem, zolang het niet verwacht dat er ook nieuwere databasefuncties zullen bestaan.
Als dat iets is waarin je geïnteresseerd bent, zal mijn lezing op de conferentie de fundamenten in kaart brengen waarop ik verwacht dat het zal worden gebouwd. Hoe dan ook, ik hoop dat u de conferentie kunt halen en kunt genieten van de lange lijst met lezingen die daar worden gepresenteerd.