Ik onderhoud een aantal projecten waarvan het doel in het leven is om het testen van delen van PostgreSQL gemakkelijker te maken. Al deze hebben de afgelopen week een behoorlijke upgrade gekregen.
stream-scaling test hoe de geheugensnelheid op servers toeneemt naarmate er meer cores in het spel worden gebracht. Het zijn fascinerende gegevens, genoeg ervan om echte trends te zien. Het werkt nu correct op systemen met grote hoeveelheden CPU-cache, omdat ze veel kernen hebben. Het was eerder mogelijk dat het zo agressief was met het dimensioneren van de testset om cache-impact te voorkomen dat het meer geheugen gebruikte dan kon worden toegewezen met het huidige ontwerp van de streamcode. Dat is teruggeschroefd. Als je een server met 48 cores of groter hebt, zou ik wat meer testen van deze nieuwe code kunnen gebruiken om te zien of de nieuwe manier waarop ik hiermee omga zinvol is.
peg is een script dat ik heb geschreven om het gemakkelijker te maken om PostgreSQL vanaf de broncode te bouwen, meestal voor ontwikkelaarswerk of voor het tijdelijk proberen van een nieuwere versie op een productiesysteem. Vroeger was het heel gemakkelijk om in de war te raken met het wisselen tussen projecten en de bijbehorende git-takken; de documentatie op dit gebied is veel verbeterd.
pgbench-tools is mijn werkhuis voor het testen van prestaties, waarmee je dagen aan benchmarkmarkeringen in de rij kunt zetten en dan voldoende analysetools beschikbaar hebt om het te begrijpen. Het programma volgt nu de recent geïntroduceerde parameter pg_stat_bgwriter.buffers_backend_fsync als je een versie hebt die dit ondersteunt (momenteel alleen een recente soure build - wat ons terugbrengt naar waarom peg nuttig is). Je kunt het ook vertellen om elke test voor een vaste hoeveelheid tijd uit te voeren, wat het testen met enorm variërende client-/groottewaarden veel gemakkelijker maakt.
Wat betreft wat je kunt doen met pgbench-tools... vanaf vandaag deel ik nu de benchmarking-tests die ik doe op PostgreSQL 9.1 op de krachtigste server waar ik onbeperkt gebruik van kan maken. 8 cores, 16 GB RAM, 3 RAID-0-databasedrives, 1 WAL-schijfvolume, Areca Battery-backed cache. U kunt de resultaten zien. Runs zijn georganiseerd in testsets, die elk een soort wijziging in de configuratie vertegenwoordigen. Bijvoorbeeld, #1 in deze data draait alleen SELECT, #2 draait TPC-B-achtig maar met 8GB RAM en ealrier code, terwijl de hot stuff #3 is, met TPC-B met 16GB RAM en code die volgt buffers_backend_fsyncs.
Er zijn verschillende patches in de PostgreSQL 9.1-wachtrij met betrekking tot de prestaties in de gebieden die door deze resultaten worden gemarkeerd - dat Linux extreem hoge latentie in het slechtste geval kan hebben bij schrijfzware databasebelastingen. Een goed gemiddeld voorbeeld is test 215:schaal van 1000, 32 clients, 365 TPS. Maar de latentie in het slechtste geval is 43 seconden en je kunt de dode hoeken zien in de TPS-grafiek. Dat is gewoon verschrikkelijk, en er zijn een paar concepten om dat te doen.
Als iemand die dit leest een krachtige server beschikbaar heeft voor een paar weken om dergelijke tests uit te voeren, zou ik u graag helpen deze omgeving te repliceren en te zien wat voor soort resultaten u ziet. De enige magie die ik heb, is wat oefening in het instellen van de schaal en clientbelastingen, zodat je niet veel tijd verliest aan onproductieve tests. De rest van mijn proces is helemaal gratis en gedocumenteerd.