Jag underhåller ett antal projekt vars syfte i livet är att göra det enklare att testa delar av PostgreSQL. Alla dessa fick en anständig uppgradering jämfört med förra veckan.
strömskalning testar hur minneshastigheten ökar på servrar när fler kärnor tas i bruk. Det är fascinerande data, tillräckligt med det för att börja se några riktiga trender. Det fungerar nu korrekt på system med stora mängder CPU-cache, eftersom de har många kärnor. Det var tidigare möjligt för det att vara så aggressivt med att dimensionera testsetet för att undvika cachepåverkan att det använde mer minne än vad som kunde allokeras med den nuvarande designen av streamkoden. Det har minskats. Om du har en server med 48 kärnor eller större, skulle jag kunna använda lite mer testning av den här nya koden för att se om det nya sättet jag hanterar det här är vettigt.
peg är ett skript jag skrev för att göra det enklare att bygga PostgreSQL från källkod, vanligtvis för utvecklararbete eller för att tillfälligt prova en nyare version på ett produktionssystem. Det var väldigt lätt att bli förvirrad med att byta mellan projekt och deras tillhörande git-grenar tidigare; dokumentationen på detta område är mycket förbättrad.
pgbench-tools är mitt arbetshus för prestandatestning, vilket gör att du kan köa dagar värda benchmark och sedan ha tillräckligt med analysverktyg tillgängliga för att förstå det. Programmet spårar nu den nyligen introducerade parametern pg_stat_bgwriter.buffers_backend_fsync om du har en version som stöder den (för närvarande bara en nyligen sur build – vilket för oss tillbaka till varför peg är användbar). Du kan också be den att köra varje test under en bestämd tid, vilket gör det mycket lättare att testa med väldigt varierande klient-/storleksvärden.
När det gäller vad du kan göra med pgbench-tools ... från och med idag delar jag med mig av benchmarking-testerna jag gör på PostgreSQL 9.1 på den mest kraftfulla servern jag har obegränsad användning av. 8 kärnor, 16 GB RAM, 3 disk RAID-0 databasenheter, 1 disk WAL volym, Areca batteristödd cache. Du kan se resultatet. Körningar är organiserade i testuppsättningar, som var och en representerar någon form av förändring av konfigurationen. Till exempel, #1 i denna data kör bara SELECT, #2 kör TPC-B-liknande men med 8 GB RAM och tidigare kod, medan det heta är #3, kör TPC-B med 16 GB RAM och kod som spårar buffers_backend_fsyncs.
Det finns flera patchar i PostgreSQL 9.1-kön relaterade till prestanda i de områden som lyfts fram av dessa resultat – att Linux kan ha extremt hög värsta tänkbara latens vid skrivtunga databasbelastningar. Ett bra genomsnittsexempel är test 215: skala på 1000, 32 klienter, 365 TPS. Men den värsta latensen är 43 sekunder, och du kan se dödpunkterna i TPS-grafen. Det är bara hemskt, och det finns några koncept för hur man gör just det.
Om någon som läser detta har en kraftfull server tillgänglig under några veckor för att köra sådana här tester, hjälper jag dig gärna att replikera den här miljön och se vilken typ av resultat du ser. Den enda magin jag har är lite övning i hur man ställer in skalningen och klientbelastningen så att du inte förlorar mycket tid på improduktiva tester. Resten av min process är helt gratis och dokumenterad.