Jednou z užitečnějších částí
dokumentace PostgreSQL, na které jsem kdy pracoval, je Vyladění vašeho PostgreSQL
Serveru. Když to bylo napsáno v létě 2008, pár měsíců po
vydání PostgreSQL 8.3, bylo těžké najít nějakou podobnou příručku,
která by byla (relativně) stručná a aktuální. Od té doby jsme já a
mnoho dalších přispěvatelů PostgreSQL pomáhali udržovat tento dokument aktuální
tak, jak byly provedeny změny v PostgreSQL.
Zajímavým a užitečným trendem
během tohoto období je, že parametry ze sady neustále mizí
těch, o které se musíte starat. V PostgreSQL 8.2 byl dlouhý
seznam parametrů, které jste pravděpodobně potřebovali upravit pro dobrý výkon
na serveru PostgreSQL:shared_buffers, efektivní_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers a (pokud používáte
rozdělení na oddíly) constraint_exclusion.
8.3 nastavilo autovakuum jako výchozí na
zapnuté s rozumným chováním, spolu s odstraněním několika
parametry zapisovače na pozadí, které nezpůsobovaly nic jiného než potíže (
nikdy se nedostaly do seznamu). 8.4 odstranil potřebu dvou parametrů
max_fsm_*, zvýšil default_statistics_target na mnohem
lepší počáteční hodnotu a učinil nastavení constraint_exclusion
zbytečným v nejběžnějších případech. To je o šest parametrů méně,
které budete pravděpodobně muset upravit.
Verze 9.0 bohužel pouze zkomplikovala
konfiguraci serveru. A novější linuxová jádra dokonce
posouvala výchozí chování zpět. Počínaje jádrem Linux
2.6.33 se výchozí hodnota vybraná pro metodu wal_sync_method změnila na
open_datasync. Ukázalo se, že to má příšerný výkon
důsledky pro PostgreSQL, zvláště v kombinaci s nízkým
výchozím nastavením pro wal_buffers na serveru.
Ale pochod směrem k lepšímu výchozímu
chování se nedávno obnovilo, jak se nakonec plánuje
PostgreSQL 9.1. Během posledního CommitFestu vznikl patch od Marti
Raudsepp k vyřešení problému wal_sync_method byl spáchán
po několika těžkých hádkách o tom, jakou formu by tato změna měla mít.
Zjištění, že tato změna chování úplně rozbila PostgreSQL
při spuštění na ext4 s možností „data=journal“ pomohlo
ve výchozím nastavení nastavit tu správnou věc.
Dva parametry, které nedoporučuji
dotýkat se ve většině případů jsou commit_siblings a commit_delay,
artefakty staršího pokusu o zlepšení výkonu na systémech s
pomalými časy potvrzení (což zahrnuje většinu systémů, které nemají
baterií zálohovanou mezipaměť pro zápis pro urychlení této oblasti). V dnešní době
mnohem pravděpodobněji pomůže vypnutí parametru synchronous_commit představeného v 8.3. I když je nepravděpodobné, že by to zlepšilo
výkon, lidé, kteří se je pokusili nastavit, utrpěli více než
nezbytně nevýhodami tohoto rozhodnutí. Nejhorší případ
chování zde bylo výrazně vylepšeno v patchi, který jsem napsal, abych optimalizoval, jak se provádí logika řízení těchto parametrů.
A tento týden posledním parametrem
který lze ve většině případů účinně eliminovat, je wal_buffers. Byla provedena změna, kterou jsem
navrhl, aby se toto nastavilo automaticky jako procento velikosti (asi 3 %)
přidělené normálně mnohem větším parametrům shared_buffers.
To nastaví hodnotu wal_buffers na normální horní hranice jeho
efektivního rozsahu, 16 MB, jakmile přidělíte
sdíleným_bufferům alespoň 512 MB. A pokud jste vůbec zvýšili shared_buffers z jeho maličkého
výchozího nastavení, získáte odpovídající zlepšení v tomto
důležitém parametru výkonu odevzdání. Budete muset ze
narušit nastavení tohoto parametru, abyste narazili na špatné
situace možné v dřívějších verzích.
Mít množství konfigurace,
které musíte na serveru ve výchozím nastavení provést, je vždy méně komplikované
stojí za to a vidět parametry mizející ze seznamu kritických je
vítaná změna. Co bude dál? Základní problémy s alokací
sdílené paměti na operačních systémech odvozených od UNIXu, zejména Linuxu,
velmi znesnadňují odstranění sdílených_bufferů. A obavy
v souvislosti se serverem přebírajícím systém zcela omezují schopnost
automaticky nastavovat parametry jako work_mem na správný rozsah.
Byly předloženy některé návrhy na lepší správu fondu pracovní paměti
navrženo, aby bylo možné vidět určité zlepšení.
Další parametr, na který se dívám, je
checkpoint_segments. Po přidání dalšího logování v této oblasti v
posledním CommitFestu došlo k několika vylepšením v této oblasti, blíží se nyní
commit, aby se skutečně zlepšilo chování kontrolních bodů. Doufám, že
nakonec přepnu ladění kontrolních bodů tak, aby bylo přísně kontrolováno
pomocí časově orientovaných parametrů, místo aby uživatelé museli
rozumět mechanismu, jak funguje protokol pro zápis napřed, aby vyladili
systém. Stále existuje příliš mnoho ošklivých situací, než abychom to mohli udělat
v době 9.1, ale automatické nastavení počtu segmentů je
pro 9.2 možné cílit.