I dag är deadline för det särskilda rumspriset på hotellet som står värd för denna månads PostgreSQL Conference East 2010. Om du har skjutit upp bokningen av en plats på konferensen, kommer det att kosta dig från och med imorgon.
Mitt föredrag handlar om Database Hardware Benchmarking och är planerat till sen eftermiddag den första dagen, torsdagen den 25 mars. De som kanske har sett det här föredraget tidigare, antingen live på PGCon 2009 eller via videolänken som finns där, kanske undrar om jag ska dra ut samma bilder och prata igen. Inte fallet; medan den allmänna filosofin för föredraget ("lita på ingen, kör dina egna riktmärken") förblir densamma, har de föreslagna exemplen och testmixen uppdaterats för att återspegla ytterligare ett års hårdvaruframsteg, PostgreSQL-arbete och min egen forskning under det. tid. Speciellt Intel vs. AMD-situationen har förändrats en hel del, vilket kräver en ny uppsättning minnesriktmärken för att verkligen följa vad som händer nu.
Och PostgreSQL 9.0 fixade ett stort problem som hindrade det från att normalt leverera korrekta resultat på Linux, på grund av en kärnregression som gjorde en redan alltför vanlig situation mycket värre: det är lätt för en enskild pgbench-klient att bli flaskhalsen när den körs, snarare än själva databasen. Granskningen jag gjorde för multi-threaded pgbench (som också kan vara multi-process pgbench på system som inte stöder trådar) föreslog en stabil>30% hastighet även på system som inte hade den dåliga kärninkompatibiliteten på dem. Efterföljande tester tyder på att det lätt kan ta 8 pgbench-processer för att få full genomströmning av även billiga moderna processorer under de senaste Linux-kärnorna. Jag ska gå igenom exakt hur det slutar med sådana system, och hur den här nya funktionen gör det möjligt igen att använda pgbench som det primära sättet att mäta CPU-prestanda som kör databasen.
Nyligen har jag också gjort en uppdatering av git-repo för pgbench-tools som lägger till fungerande stöd för PostgreSQL 8.4 och grundläggande 9.0-kompatibilitet, och nästa uppdatering kommer att innehålla stöd för det flertrådiga alternativet nu när jag har kartlagt hur det behöver arbeta. Allt detta leder någonstans. När vi väl har korrekta mätningar för PostgreSQL-prestanda som är CPU-begränsade på serversidan, något som inte ofta har varit fallet i över två år nu, blir de återigen ett användbart sätt att övervaka prestandaregressioner i PostgreSQL-kodbasen. Testerna som ingår kommer att behöva utökas för att det ska täcka mer så småningom, men för närvarande har vi nått en punkt där pgbench kan användas för att hitta regressioner som påverkar hur snabbt enkla SELECT-satser körs. Jag vet att det fungerar som förväntat, för varje gång jag av misstag bygger PostgreSQL med påståenden fångas det eftersom jag ser den genomsnittliga bearbetningshastigheten sjunka dramatiskt.
När jag väl har ett par systeminstallationer här för att testa för sådana regressioner, blir frågan hur man automatiserar det jag gör och sedan gör samma sak mot ett bredare utbud av byggutcheckningar. Helst skulle du kunna se en graf över genomsnittlig SELECT-prestanda varje dag, uppdelad efter version, så att när en commit som minskade den infördes skulle det omedelbart vara uppenbart när prestandan sjönk. Detta är drömmålet för att bygga en prestationsfarm som liknar PostgreSQL buildfarm. Delarna är nästan alla tillsammans nu: mina pgbench-delar håller på att avslutas, förlängningar av buildfarm för att få den att tala direkt till git går vidare (inte ett krav, men ingen som arbetar med det här projektet vill använda CVS om vi kan undvika det) , och det viktigaste som saknas vid det här laget är någon att lägga tid på att integrera det jag har gjort i en buildfarm-liknande klient.
Och det ser ut som att vi nu har en företagssponsor som är villig att hjälpa till med den biten av arbete, som jag kommer att låta ta äran för när vi alla är klara, och det är planerat att ske i sommar. Jag förväntar mig fullt ut att PostgreSQL 9.1-utveckling och 9.0-backpatching kommer att ske med en tidig prestandafarm på plats för att skydda mot prestandaregressioner. Om vi kan backportera den nya flertrådiga pgbench till äldre PostgreSQL-versioner kan vi även inkludera dem i mixen. Jag har redan en backport av 8.3 pgbench, som har många förbättringar, jag underhåller bara för att testa 8.2-system. Med pgbench som en ganska fristående bidragsmodul är det möjligt att bygga en senare som skiljer sig från resten av systemet, så länge den inte förväntar sig att nyare databasfunktioner också ska finnas.
Om det är något du är intresserad av, kommer mitt föredrag på konferensen att kartlägga de grunder jag förväntar mig att den ska bygga på. Oavsett vilket, hoppas du kan ta dig till konferensen och njuta av den långa listan med föredrag som presenteras där.