sql >> Databáze >  >> RDS >> PostgreSQL

PGEast, Hardware Benchmarking a PG Performance Farm

Dnes je konečný termín pro speciální cenu pokoje v hotelu, který tento měsíc pořádá konferenci PostgreSQL East 2010.  Pokud odkládáte rezervaci místa na konferenci, od zítřka vás to začne stát.

Moje přednáška je o srovnávání databázového hardwaru a je naplánována na pozdní odpoledne prvního dne, ve čtvrtek 25. března. Ti, kteří tuto přednášku mohli vidět již dříve, ať už živě na PGCon 2009, nebo prostřednictvím odkazu na video, který je tam k dispozici, by se mohli ptát, zda nevytáhnu stejné snímky a budu mluvit znovu. Není tomu tak; zatímco obecná filozofie přednášky („nikomu nevěř, spouštěj vlastní benchmarky“) zůstává stejná, příklady a navrhovaný mix testů byly aktualizovány, aby odrážely další rok pokroky v hardwaru, práci PostgreSQL a můj vlastní výzkum během toho čas. Zejména situace Intel vs. AMD se dost změnila a vyžaduje novou sadu paměťových benchmarků, aby skutečně odpovídala tomu, co se nyní děje.

A PostgreSQL 9.0 vyřešil hlavní problém, který mu bránil v normálním poskytování přesných výsledků na Linuxu, kvůli regresi jádra, která značně zhoršila již tak příliš běžnou situaci:Je snadné, aby se jeden klient pgbench stal úzkým hrdlem při jeho spuštění, spíše než samotná databáze. Recenze, kterou jsem provedl pro vícevláknový pgbench (což může být také víceprocesový pgbench na systémech, které nepodporují vlákna), naznačila solidní>30% zrychlení i na systémech, které na sobě neměly špatnou nekompatibilitu jádra. Následné testování naznačuje, že k získání plné propustnosti i z levných moderních procesorů v nejnovějších linuxových jádrech může snadno trvat 8 procesů pgbench. Projdu si přesně, jak se to na takových systémech projeví a jak tato nová funkce opět umožňuje použít pgbench jako primární způsob měření výkonu procesoru provozujícího databázi.

Nedávno jsem také aktualizoval git repo pro pgbench-tools, které přidává funkční podporu pro PostgreSQL 8.4 a základní kompatibilitu 9.0 a další aktualizace bude zahrnovat podporu pro vícevláknovou možnost, když jsem zmapoval, jak to potřebuje pracovat. Tohle všechno někam vede. Jakmile máme přesná měření výkonu PostgreSQL, která jsou na straně serveru omezena CPU, což se již více než dva roky často nestává, stávají se opět užitečným způsobem sledování regresí výkonu v kódové základně PostgreSQL. Zahrnuté testy budou muset být rozšířeny, aby nakonec pokryly více, ale nyní jsme dosáhli bodu, kdy lze pgbench použít k nalezení regresí, které ovlivňují, jak rychle se provádějí jednoduché příkazy SELECT. Vím, že to funguje podle očekávání, protože pokaždé, když omylem sestavím PostgreSQL s tvrzeními, je to zachyceno, protože vidím, že průměrná rychlost zpracování dramaticky klesá.

Jakmile zde nastavím několik systémů pro testování takových regresí, vyvstává otázka, jak automatizovat to, co dělám, a pak udělat totéž s širším rozsahem pokladen sestavení. V ideálním případě byste mohli vidět graf průměrného výkonu SELECT každý den, rozdělený podle verzí, takže když byl zaveden závazek, který ho snížil, bylo okamžitě zřejmé, kdy výkon klesl. To je vysněný cíl pro vybudování výkonnostní farmy podobné buildfarmě PostgreSQL. Části jsou nyní téměř všechny pohromadě:  moje části pgbench se uzavírají, rozšíření na buildfarm, aby mohla mluvit přímo s git, se pohybují (není podmínkou, ale nikdo pracující na tomto projektu nechce používat CVS, pokud se tomu můžeme vyhnout) , a hlavní věc, která v tomto bodě chybí, je někdo, kdo by věnoval čas integraci toho, co jsem dělal, do klienta typu buildfarm.

A vypadá to, že teď máme firemního sponzora, který je ochotný pomoci s tím kusem práce, kterému se zavděčím, až budeme všichni hotoví, a to se má stát letos v létě. Plně očekávám, že vývoj PostgreSQL 9.1 a backpatching 9.0 proběhnou se zavedenou farmou raného výkonu, která bude chránit před regresemi výkonu. Pokud dokážeme backportovat nový vícevláknový pgbench na starší verze PostgreSQL, mohli bychom je zahrnout také do mixu. Už mám backport 8.3 pgbench, který má spoustu vylepšení, udržuji jen pro testování 8.2 systémů. S pgbench jako docela samostatným modulem contrib je možné později sestavit modul odlišný od zbytku systému, pokud neočekává, že budou existovat i novější databázové funkce.

Pokud je to něco, co vás zajímá, moje přednáška na konferenci zmapuje základy, na kterých očekávám, že bude postavena. Bez ohledu na to doufám, že se na konferenci dostanete a užijte si dlouhý seznam přednášek, které jsou na ní prezentovány.


  1. MySQL – Udělejte ze stávajícího pole jedinečný

  2. Nechte uživatele MySQL vytvářet databáze, ale povolte přístup pouze k jejich vlastním databázím

  3. Jak zadat název primárního klíče v EF-Code-First

  4. Jak vypočítat procento růstu po měsíci v MySQL