Nejprve vždy používejte nejnovější verzi PostgreSQL. Vylepšování výkonu stále přichází, takže pokud ladíte starou verzi, pravděpodobně ztrácíte čas. Například PostgreSQL 9.2 výrazně zlepšuje rychlost TRUNCATE a samozřejmě přidává skenování pouze s indexem. I malá vydání by měla být vždy dodržována; viz zásady verze.
Ne
NEDĚLEJTE umístěte tabulkový prostor na RAMdisk nebo jiné netrvanlivé úložiště.
Pokud ztratíte tabulkový prostor, celá databáze může být poškozena a těžko použitelná bez značné práce. Ve srovnání s pouhým použitím UNLOGGED to má jen velmi malou výhodu tabulky a každopádně mít spoustu paměti RAM pro mezipaměť.
Pokud opravdu chcete systém založený na ramdisku, initdb zcela nový cluster na ramdisku pomocí initdb přidáním nové instance PostgreSQL na ramdisku, takže máte zcela jednorázovou instanci PostgreSQL.
Konfigurace serveru PostgreSQL
Při testování můžete svůj server nakonfigurovat pro méně odolný, ale rychlejší provoz.
Toto je jedno z mála přijatelných použití pro fsync=off nastavení v PostgreSQL. Toto nastavení do značné míry říká PostgreSQL, aby se neobtěžoval s řízenými zápisy nebo jinými ošklivými ochranami integrity dat a bezpečností při haváriích, což mu dává oprávnění zcela zničit vaše data, pokud ztratíte napájení nebo dojde k selhání operačního systému.
Netřeba říkat, že byste nikdy neměli povolit fsync=off v produkci, pokud nepoužíváte Pg jako dočasnou databázi pro data, která můžete znovu generovat odjinud. Pokud a pouze v případě, že chcete vypnout fsync, můžete také zapnout full_page_writes vypnout, protože už to nedělá dobrotu. Pozor, fsync=off a full_page_writes použít v klastru úroveň, takže ovlivňují všechny databáze ve vaší instanci PostgreSQL.
Pro produkční použití můžete případně použít synchronous_commit=off a nastavte commit_delay , protože získáte mnoho stejných výhod jako fsync=off bez velkého rizika poškození dat. Pokud povolíte asynchronní odevzdání, máte malé okno ztráty posledních dat – ale to je vše.
Pokud máte možnost mírně změnit DDL, můžete také použít UNLOGGED tabulky v Pg 9.1+, abyste se zcela vyhnuli protokolování WAL a získali skutečné zvýšení rychlosti za cenu vymazání tabulek v případě pádu serveru. Neexistuje žádná možnost konfigurace, která by odhlásila všechny tabulky, musí být nastavena během CREATE TABLE . Kromě toho, že je to dobré pro testování, je to užitečné, pokud máte tabulky plné generovaných nebo nedůležitých dat v databázi, která jinak obsahuje věci, které musíte být v bezpečí.
Zkontrolujte své protokoly a zjistěte, zda nedostáváte upozornění na příliš mnoho kontrolních bodů. Pokud ano, měli byste zvýšit své checkpoint_segments. Můžete také vyladit svůj checkpoint_completion_target, aby se vypisovaly plynule.
Vylaďte shared_buffers aby vyhovovalo vaší pracovní zátěži. To je závislé na operačním systému, závisí na tom, co se děje s vaším počítačem, a vyžaduje určité pokusy a omyly. Výchozí hodnoty jsou extrémně konzervativní. Pokud zvýšíte shared_buffers, možná budete muset zvýšit maximální limit sdílené paměti operačního systému na PostgreSQL 9.2 a níže; 9.3 a vyšší změnily způsob používání sdílené paměti, aby se tomu zabránilo.
Pokud používáte jen pár připojení, která dělají spoustu práce, zvyšte work_mem dát jim více paměti RAM na hraní atd. Pozor, příliš vysoká hodnota work_mem nastavení může způsobit problémy s nedostatkem paměti, protože je to na řazení, nikoli na připojení, takže jeden dotaz může mít mnoho vnořených druhů. Vy pouze skutečně muset zvýšit work_mem pokud v EXPLAIN vidíte, jak se řazení sype na disk nebo přihlášeni pomocí log_temp_files nastavení (doporučeno), ale vyšší hodnota může také umožnit Pg vybrat chytřejší plány.
Jak řekl jiný plakát zde, je rozumné umístit xlog a hlavní tabulky/indexy na samostatné HDD, pokud je to možné. Oddělené oddíly jsou docela zbytečné, opravdu chcete samostatné jednotky. Toto oddělení má mnohem menší přínos, pokud používáte fsync=off a téměř žádný, pokud používáte UNLOGGED tabulky.
Nakonec dolaďte své dotazy. Ujistěte se, že vaše random_page_cost a seq_page_cost odrážejí výkon vašeho systému, zajistěte effective_cache_size je správné atd. Použijte EXPLAIN (BUFFERS, ANALYZE) prozkoumejte jednotlivé plány dotazů a zapněte auto_explain modul na hlásit všechny pomalé dotazy. Výkon dotazů můžete často výrazně zlepšit pouhým vytvořením vhodného indexu nebo úpravou parametrů nákladů.
AFAIK neexistuje způsob, jak nastavit celou databázi nebo cluster jako UNLOGGED . Bylo by zajímavé to udělat. Zvažte dotaz na PostgreSQL mailing list.
Ladění operačního systému hostitele
Určité ladění můžete provést i na úrovni operačního systému. Hlavní věc, kterou možná budete chtít udělat, je přesvědčit operační systém, aby agresivně nevymazával zápisy na disk, protože je vám opravdu jedno, kdy/jestli se dostanou na disk.
V Linuxu to můžete ovládat pomocí dirty_* subsystému virtuální paměti nastavení, například dirty_writeback_centisecs .
Jediný problém s laděním nastavení zpětného zápisu tak, aby bylo příliš ochablé, je to, že vyprázdnění jiným programem může způsobit vyprázdnění všech nahromaděných vyrovnávacích pamětí PostgreSQL, což způsobí velké zablokování, zatímco vše blokuje zápisy. Možná to budete moci zmírnit spuštěním PostgreSQL na jiném souborovém systému, ale některá vyprázdnění mohou být na úrovni zařízení nebo celého hostitele, nikoli na úrovni souborového systému, takže se na to nemůžete spolehnout.
Toto ladění skutečně vyžaduje pohrát si s nastavením, abyste zjistili, co nejlépe vyhovuje vaší pracovní zátěži.
Na novějších jádrech možná budete chtít zajistit, aby vm.zone_reclaim_mode je nastaven na nulu, protože může způsobit vážné problémy s výkonem u systémů NUMA (dnes většina systémů) kvůli interakcím s tím, jak PostgreSQL spravuje shared_buffers .
Ladění dotazů a zátěže
To jsou věci, které vyžadují změny kódu; nemusí vám vyhovovat. Některé věci byste mohli použít.
Pokud nerozdělujete práci do větších transakcí, začněte. Spousta malých transakcí je drahých, takže byste měli dávkovat věci, kdykoli je to možné a praktické. Pokud používáte asynchronní potvrzení, je to méně důležité, ale přesto vysoce doporučeno.
Kdykoli je to možné, používejte dočasné tabulky. Negenerují provoz WAL, takže jsou mnohem rychlejší pro vkládání a aktualizace. Někdy se vyplatí dát do dočasné tabulky spoustu dat, zpracovat je, jak potřebujete, a poté provést INSERT INTO ... SELECT ... pro zkopírování do finálového stolu. Všimněte si, že dočasné tabulky jsou na relaci; pokud vaše relace skončí nebo ztratíte připojení, dočasná tabulka zmizí a žádné jiné připojení neuvidí obsah dočasných tabulek relace.
Pokud používáte PostgreSQL 9.1 nebo novější, můžete použít UNLOGGED tabulky pro data, která si můžete dovolit ztratit, jako je stav relace. Ty jsou viditelné v různých relacích a jsou zachovány mezi připojeními. Jsou zkráceny, pokud se server nečistě vypne, takže je nelze použít pro nic, co nemůžete znovu vytvořit, ale jsou skvělé pro mezipaměti, materializované pohledy, tabulky stavů atd.
Obecně platí, že DELETE FROM blah; . Použijte TRUNCATE TABLE blah; namísto; je to mnohem rychlejší, když vyhazujete všechny řádky v tabulce. Zkrátit mnoho tabulek v jednom TRUNCATE zavolej, jestli můžeš. Pokud děláte hodně TRUNCATES, existuje upozornění stále znovu a znovu malých stolků; viz:Rychlost zkrácení Postgresql
Pokud nemáte indexy cizích klíčů, DELETE s zahrnující primární klíče odkazované těmito cizími klíči budou strašně pomalé. Pokud někdy očekáváte DELETE, nezapomeňte takové indexy vytvořit z odkazovaných tabulek. Indexy nejsou vyžadovány pro TRUNCATE .
Nevytvářejte indexy, které nepotřebujete. Každý index má náklady na údržbu. Pokuste se použít minimální sadu indexů a nechte skenování bitmapových indexů je kombinovat, spíše než udržovat příliš mnoho obrovských, drahých vícesloupcových indexů. Tam, kde jsou vyžadovány indexy, zkuste nejprve naplnit tabulku a na konci vytvořte indexy.
Hardware
Mít dostatek paměti RAM pro uložení celé databáze je obrovská výhra, pokud ji dokážete spravovat.
Pokud nemáte dostatek paměti RAM, čím rychlejší úložiště můžete získat, tím lépe. Dokonce i levný SSD je obrovský rozdíl oproti rotující rzi. Nevěřte však levným SSD pro výrobu, často nejsou bezpečná a mohou vám sežrat data.
Učení
Kniha Grega Smithe PostgreSQL 9.0 High Performance zůstává relevantní i přes odkaz na poněkud starší verzi. Měla by to být užitečná reference.
Připojte se k obecnému mailing listu PostgreSQL a sledujte jej.
Čtení:
- Vyladění vašeho PostgreSQL serveru – PostgreSQL wiki
- Počet databázových připojení – PostgreSQL wiki