Provozuji řadu projektů, jejichž smyslem života je usnadnit testování částí PostgreSQL. Všechny tyto prošly minulý týden slušným upgradem.
stream-scaling testuje, jak se zvyšuje rychlost paměti na serverech, když se do hry dostává více jader. Jsou to fascinující data, je jich dost na to, abyste začali vidět nějaké skutečné trendy. Nyní funguje správně na systémech s velkým množstvím mezipaměti CPU, protože mají mnoho jader. Dříve bylo možné, že byl tak agresivní při dimenzování testovací sady, aby se zabránilo dopadu na mezipaměť, že spotřeboval více paměti, než by bylo možné alokovat se současným návrhem kódu streamu. To bylo zmenšeno. Pokud máte 48jádrový server nebo větší, mohl bych použít další testování tohoto nového kódu, abych zjistil, zda nový způsob, jakým to řeším, dává smysl.
peg je skript, který jsem napsal, abych usnadnil sestavení PostgreSQL ze zdroje, obvykle pro práci vývojáře nebo pro dočasné vyzkoušení novější verze na produkčním systému. Dříve bylo velmi snadné se splést s přepínáním mezi projekty a jejich přidruženými větvemi git; dokumentace v této oblasti je mnohem vylepšena.
pgbench-tools je moje pracoviště pro testování výkonu, které vám umožňuje zařadit do fronty několik dní v hodnotě benchmarku a poté mít k dispozici dostatek analytických nástrojů, abyste tomu dali smysl. Program nyní sleduje nedávno představený parametr pg_stat_bgwriter.buffers_backend_fsync, pokud máte verzi, která jej podporuje (v současnosti pouze nedávná nevhodná sestavení – což nás přivádí zpět k tomu, proč je peg užitečný). Můžete mu také říct, aby spouštěl každý test po pevně stanovenou dobu, díky čemuž je testování na velmi odlišných hodnotách klient/velikost mnohem jednodušší.
Pokud jde o to, co můžete dělat s pgbench-tools...dnes sdílím srovnávací testy, které dělám na PostgreSQL 9.1 na nejvýkonnějším serveru, který neomezeně využívám. 8 jader, 16 GB RAM, 3 diskové databázové jednotky RAID-0, 1 diskový svazek WAL, mezipaměť zálohovaná baterií Areca. Můžete vidět výsledky. Běhy jsou organizovány do testovacích sad, z nichž každá představuje určitý druh změny konfigurace. Například #1 v těchto datech běží pouze SELECT, #2 běží jako TPC-B, ale s 8 GB RAM a starším kódem, zatímco nejžhavější je #3, běží TPC-B s 16 GB RAM a kódem, který tracks buffers_backend_fsyncs.
Ve frontě PostgreSQL 9.1 existuje několik záplat souvisejících s výkonem v oblastech zvýrazněných těmito výsledky – že Linux může mít extrémně vysokou latenci nejhoršího případu při zatížení databáze s velkým množstvím zápisu. Dobrým průměrným příkladem je test 215: škála 1000, 32 klientů, 365 TPS. Ale nejhorší latence je 43 sekund a hluchá místa můžete vidět v grafu TPS. To je prostě hrozné a existuje několik konceptů, jak to udělat.
Pokud má někdo, kdo toto čte, k dispozici výkonný server na několik týdnů, aby na něm mohl spouštět testy, jako je tento, rád vám pomohu replikovat toto prostředí a uvidíte, jaké výsledky uvidíte. Jediné kouzlo, které mám, je určitá praxe v tom, jak nastavit škálování a zatížení klienta, abyste neztráceli spoustu času neproduktivními testy. Zbytek mého procesu je zdarma a zdokumentován.