I dag er deadline for den særlige værelsespris på hotellet, der er vært for denne måneds PostgreSQL Conference East 2010. Hvis du har tøvet med at reservere en plads til konferencen, vil det fra i morgen begynde at koste dig.
Mit foredrag handler om Database Hardware Benchmarking og er planlagt til sent på eftermiddagen den første dag, torsdag den 25. marts. De, der måske har set dette foredrag før, enten live på PGCon 2009 eller via videolinket, der er tilgængeligt der, spekulerer måske på, om jeg vil trække de samme dias ud og tale igen. Ikke tilfældet; mens foredragets generelle filosofi ("stol på ingen, kør dine egne benchmarks") forbliver den samme, er de foreslåede eksempler og testmix blevet opdateret for at afspejle endnu et års hardwarefremskridt, PostgreSQL-arbejde og min egen forskning i løbet af det. tid. Især Intel vs. AMD-situationen har ændret sig en del, hvilket kræver et nyt sæt hukommelsesbenchmarks for virkelig at følge, hvad der sker nu.
Og PostgreSQL 9.0 løste et stort problem, der forhindrede det i normalt at levere nøjagtige resultater på Linux på grund af en kerneregression, der gjorde en allerede alt for almindelig situation meget værre: det er nemt for en enkelt pgbench-klient at blive flaskehalsen, når den kører, snarere end selve databasen. Den anmeldelse, jeg lavede for multi-threaded pgbench (som også kan være multi-proces pgbench på systemer, der ikke understøtter tråde) foreslog en solid>30% speedup, selv på systemer, der ikke havde den dårlige kerne-inkompatibilitet på dem. Efterfølgende test tyder på, at det nemt kan tage 8 pgbench-processer at få fuld gennemstrømning ud af selv billige moderne processorer under nyere Linux-kerner. Jeg vil gennemgå præcis, hvordan det ender med at spille på sådanne systemer, og hvordan denne nye funktion gør det muligt igen at bruge pgbench som den primære måde at måle CPU-ydeevne, der kører databasen.
For nylig har jeg også lavet en opdatering til git-repoen til pgbench-tools, der tilføjer fungerende understøttelse af PostgreSQL 8.4 og grundlæggende 9.0-kompatibilitet, og den næste opdatering vil inkludere understøttelse af multi-threaded-indstillingen nu, hvor jeg har kortlagt, hvordan det skal arbejde. Det hele fører et sted hen. Når vi først har præcise målinger for PostgreSQL-ydeevne, der er CPU-begrænset på serversiden, noget der ikke ofte har været tilfældet i over to år nu, bliver de igen en nyttig måde at overvåge for ydeevneregressioner i PostgreSQL-kodebasen. De inkluderede tests skal udvides for at dække mere i sidste ende, men for nu har vi nået et punkt, hvor pgbench kan bruges til at finde regressioner, der påvirker, hvor hurtigt simple SELECT-sætninger udføres. Jeg ved, at det fungerer som forventet, for hver gang jeg ved et uheld bygger PostgreSQL med påstande om, bliver det fanget, fordi jeg ser den gennemsnitlige behandlingshastighed falde dramatisk.
Når jeg har fået et par systemopsætninger her til at teste for sådanne regressioner, bliver spørgsmålet, hvordan man automatiserer det, jeg laver, og derefter gør det samme mod en bredere vifte af build-checkouts. Ideelt set ville du være i stand til at se en graf over den gennemsnitlige SELECT-ydelse hver dag, opdelt efter version, så når en commit, der reducerede den, blev introduceret, ville det straks være tydeligt, hvornår ydeevnen faldt. Dette er drømmemålet for at bygge en præstationsfarm, der ligner PostgreSQL buildfarm. Stykkerne er næsten alle sammen nu: mine pgbench-dele er ved at pakke sammen, udvidelser til buildfarm for at få den til at tale direkte til git bevæger sig (ikke et krav, men ingen, der arbejder på dette projekt, ønsker at bruge CVS, hvis vi kan undgå det) , og det vigtigste, der mangler på dette tidspunkt, er nogen til at bruge tid på at integrere det, jeg har lavet i en buildfarm-lignende klient.
Og det ser ud til, at vi nu har en virksomhedssponsor, der er villig til at hjælpe med det stykke arbejde, som jeg vil lade tage æren for, når vi alle er færdige, og det er planlagt til at ske til sommer. Jeg forventer fuldt ud, at PostgreSQL 9.1-udvikling og 9.0-backpatching vil ske med en tidlig præstationsfarm på plads for at beskytte mod præstationsregressioner. Hvis vi kan backportere den nye multi-threaded pgbench til ældre PostgreSQL-versioner, kan vi måske også inkludere dem i blandingen. Jeg har allerede en backport af 8.3 pgbench, som har en masse forbedringer, jeg vedligeholder kun for at teste 8.2-systemer. Med pgbench som et ret selvstændigt bidragsmodul er det muligt at bygge et senere, der er forskelligt fra resten af systemet, så længe det ikke forventer, at der også findes nyere databasefunktioner.
Hvis det er noget, du er interesseret i, vil mit foredrag på konferencen kortlægge det grundlag, jeg forventer, at det bygges på. Uanset hvad, håber du kan komme til konferencen og nyde den lange liste af foredrag, der bliver præsenteret der.