Jeg vedligeholder en række projekter, hvis formål i livet er at gøre det nemmere at teste dele af PostgreSQL. Alle disse fik en anstændig opgradering i forhold til denne sidste uge.
stream-skalering tester, hvordan hukommelseshastigheden stiger på servere, efterhånden som flere kerner bringes i spil. Det er fascinerende data, nok af det til at begynde at se nogle rigtige tendenser. Det fungerer nu korrekt på systemer med store mængder CPU-cache, fordi de har mange kerner. Det var tidligere muligt for det at være så aggressivt med at dimensionere testsættet for at undgå cachepåvirkning, at det brugte mere hukommelse, end der kunne allokeres med det aktuelle design af streamkoden. Det er blevet reduceret. Hvis du har en 48 core server eller større, kunne jeg bruge nogle flere test af denne nye kode for at se, om den nye måde, jeg håndterer dette på, giver mening.
peg er et script, jeg skrev for at gøre det nemmere at bygge PostgreSQL fra kilden, typisk til udviklerarbejde eller for midlertidigt at prøve en nyere version på et produktionssystem. Det var meget nemt at blive forvirret med at skifte mellem projekter og deres tilhørende git-grene før; dokumentationen på dette område er meget forbedret.
pgbench-tools er mit arbejdssted for præstationstestning, der giver dig mulighed for at stille dage i kø for benchmarkmærke og derefter have nok analyseværktøjer til rådighed til at give mening ud af det. Programmet sporer nu den nyligt introducerede pg_stat_bgwriter.buffers_backend_fsync parameter, hvis du har en version, der understøtter det (i øjeblikket kun en nylig sur build – hvilket bringer os tilbage til, hvorfor peg er nyttig). Du kan også fortælle den, at den skal køre hver test i et fast tidsrum, hvilket gør det meget nemmere at teste med meget varierende klient-/størrelsesværdier.
For så vidt angår hvad du kan gøre med pgbench-tools...fra i dag deler jeg nu de benchmarkingtest, jeg laver på PostgreSQL 9.1 på den mest kraftfulde server, jeg har ubegrænset brug af. 8 kerner, 16 GB RAM, 3 disk RAID-0 databasedrev, 1 disk WAL volumen, Areca batteri-understøttet cache. Du kan se resultaterne. Kørsler er organiseret i testsæt, som hver repræsenterer en form for ændring af konfigurationen. For eksempel kører #1 i disse data kun SELECT, #2 kører TPC-B-lignende, men med 8 GB RAM og tidligere kode, mens det hotteste er #3, kører TPC-B med 16 GB RAM og kode, der sporer buffers_backend_fsyncs.
Der er adskillige patches i PostgreSQL 9.1-køen relateret til ydeevne i de områder, der fremhæves af disse resultater – at Linux kan have ekstremt høj værst tænkelig latency på skrivetunge databasebelastninger. Et godt gennemsnitseksempel er test 215: skala på 1000, 32 klienter, 365 TPS. Men den værste forsinkelse er 43 sekunder, og du kan se dødpunkterne i TPS-grafen. Det er bare forfærdeligt, og der er et par koncepter, der flyder rundt for, hvordan man gør netop det.
Hvis nogen, der læser dette, har en kraftfuld server tilgængelig i et par uger til at køre test som denne på, vil jeg med glæde hjælpe dig med at replikere dette miljø og se, hvilken slags resultater du ser. Den eneste magi, jeg har, er lidt øvelse i, hvordan man indstiller skaleringen og klientbelastningen, så du ikke mister en masse tid til uproduktive tests. Resten af min proces er gratis og dokumenteret.