přejít na obsah přejít na navigaci

Linux E X P R E S, Optimalizace PostgreSQL: Čemu se raději vyhnout

Optimalizace PostgreSQL: Čemu se raději vyhnout

postgresql.png

Kompletní konfigurace databáze PostgreSQL obsahuje velmi mnoho položek k nastavení (něco přes dvě stě). Některé z nich mohou přinést očekávané zvýšení výkonu, jiné ovšem mohou zapříčinit ztrátu dat. V dnešním díle se zaměříme na konfigurační volby, kterým byste se při nastavování běžného databázového serveru měli raději vyhnout.


reklama

fsync

Nastavením způsobu synchronizace datových souborů jsme se zabývali již v minulém dílu u parametru wal_sync_method a výběru správného způsobu synchronizace s ohledem na bezpečnost dat na disku. Nastavení fsync=off synchronizaci dat na disk vypíná zcela. Toto nastavení sice zrychlí práci databáze (ukládání dat na disk) na možné maximum (databázový server se nebude vůbec starat o bezpečné zapsání dat na disk), ale také významně ohrozí data při pádu serveru (výpadek elektrické energie, chyba hardwaru a také i chyba softwarová). Při běžném použití PostgreSQL je proto nutné vždy nechat synchronizaci zapnutou (nastavení fsync=on).

Existují ale výjimečné situace, kdy je možné synchronizaci zcela vypnout. Jsou to případy, kdy je potřeba velmi rychle nahrát již existující data do databáze (například obnovení ze zálohy). V takovém případě k ohrožení dat nedojde, protože i při případném výpadku databáze jsou data stále k dispozici. Po nahrání dat je ovšem nutné (pro další provoz) synchronizaci opět zapnout.

Dalším speciálním případem, kdy je možné synchronizaci vypnout, jsou slave servery (například pro účely náročnějších dotazů, které by zbytečně dlouhodobě zaměstnávaly master server), kdy jsou data replikována z masteru. Opět, data jsou k dispozici a pokud dojde k jejich ztrátě na slave serveru, lze je získat opět z mastera.

Tak či onak, je důležité vědět, že toto nastavení přímo ovlivňuje bezpečí dat a při vypnuté synchronizaci a následném výpadku (z různých důvodů), téměř jistě dojde k neopravitelnému poškození datových souborů. Na druhou stranu existují situace, kdy je takto získaná rychlost přednější a data je (po výpadku) možno opět získat odjinud.

full_page_writes

Také nastavení full_page_writes se přímo týká bezpečnosti dat na disku podobně jako fsync a v běžném provozu je nutné nechat nastavení na výchozím full_page_writes = on. Při vypnutí kompletních zápisů stránky může (při havárii) dojít k poškození souborů WAL logu (a tedy neopravitelnému poškození dat) a dokonce k horšímu, nedetekovatelnému, poškození a k tzv. silent data corruption (data jsou formálně v pořádku, ale hodnoty jsou změněné). Toto poškození dat se velmi složitě odhaluje a může prorůstat do dalších systémů.

max_prepared_transactions

Mnoho lidí (pozn. autora: i mě to prvně v konfiguračním souboru zmátlo) si nastavení max_prepared_transactions dává mylně do souvislosti s technikou připravených příkazů (prepared statement), kdy si lze připravit příkaz a opakovaně jej volat s jinými parametry. Tato volba slouží pro nastavení počtu připravených transakcí pro dvoufázový commit. V drtivě většině běžných nasazení PostgreSQL je možné tuto volbu nechat ve výchozím nastavení.

„Rady“ optimalizátoru dotazů

Je celá řada nastavení týkajících se optimalizátoru prováděcího plánu, které lze navíc volat i v rámci připojení klienta. Někteří programátoři je používají (či spíše zneužívají) jako rady optimalizátoru plánu, který z nějakého důvodu nepoužije optimální způsob vykonání dotazu. K tomuto použití též částečně nahrává fakt, že PostgreSQL v dotazech nepodporuje rady (hints), které mají jiné databázové servery. Občas tak lze v SQL kódu zahlédnout řádky, které tam nepatří, například zde se zakazuje průchod celou tabulkou, použije se průchod pomocí indexu:

set enable_seqscan = off

Obecně je to velmi špatná technika. V nových verzích PostgreSQL se optimalizátor plánu a vykonávání dotazů optimalizuje a tyto nevhodné „nápovědy“ jej pak zbytečně omezují. Pokud optimalizátor z nějakého důvodu nevybere optimální plán, je často možné dotaz přestavět jinak, nastavit větší počet statistických hodnot pro vybrané sloupce apod.

Shrnutí

Výchozí nastavení PostgreSQL serveru je velmi úsporné. Co se týče paměťových nároků, někdy možná až příliš bezpečné, co se ukládání dat týče a v neposlední řadě také příliš tiché, z hlediska informací ukládaných do logů. Administrátor potřebuje především vědět, co se v jeho serveru děje, k čemuž mu slouží záznamy v logách. Server vyžaduje jistou péči a také znalosti o uložených datech. Toto nastavení jsme si ukázali hned na začátku seriálu, v prvním dílu.

Uživatel chce mít svá data rychle k dispozici, ale také v bezpečí. Jak správně v PostgreSQL nastavit rychlý a bezpečný způsob práce s diskem, jsme probrali zejména ve druhém dílu. Databázový server vyžaduje co největší množství paměti, které musí být pečlivě zvoleno a nastaveno k různým účelům. Tím jsme se zabývali ve třetím dílu.

Cílem tohoto seriálu bylo ukázat alespoň některá nastavení a jejich vhodné hodnoty s cílem získat z databázového serveru co nejvyšší výkon a administrátorský komfort.

Nahoru

(Jako ve škole)
Průměr: 1,00 | Hodnotilo: 4
 

Top články z OpenOffice.cz

Příspěvky

Optimalizace PostgreSQL: Čemu se raději vyhnout
rr5 29. 04. 2011, 09:08:48
Odpovědět  Odkaz 
Chcel by som podakovat autorovi za celu tuto seriu clankov,
vynikajuco napisane, a vhodne aj pre nas, maniakov do postgres..
Tomáš Crhonek Re:Optimalizace PostgreSQL: Čemu se raději vyhnout
Tomáš Crhonek 29. 04. 2011, 09:41:53
Odpovědět  Odkaz 
Díky. Ještě plánuji jeden díl, kde bych chtěl shrnout všechna důležitá (pro výkon) nastavení do jednoho konfiguračního souboru a k tomu též ukázat nějaké testy (TPC-B) výkonnosti.
Optimalizace PostgreSQL: Čemu se raději vyhnout
Honza 13. 05. 2011, 11:18:18
Odpovědět  Odkaz 
mel bych otazku na redakci. Napr. u tohoto clanku by me zajimala ctenost - t.j. kolik lidi si to precetlo. Na jinych webech maji obcas takove udaje pod clankem.

Duvodem je, ze bych rad vedel, jestli se takove clanky se silne technickym 'backgroundem' vyplati psat. Pozoruji, ze mnohem vice 'frci' takove ty recenze ruznych distribuci a pod. (tedy na jinych webech, kde ty udaje o ctenosti publikuji).

Samozrejme, diky autorovi za informace ohledne pgsql. Myslim si, ze by bylo prinosne, aby mohl 'bezny' admin, ktery se nezabyva pouze DB 'nahrat' nejakou 'overenou' (doporucenou) kombinaci parametru pro urcity typ nasazeni (napr. firma 20 user, 20 GB dat, 100 tabulek ..)

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Tomáš Crhonek

Tomáš Crhonek

Pracuji jako administrátor linuxových serverů ve společnosti QCM. Zabývám se především optimalizací DB strojů, zejména PostgreSQL. Hraji si též se storage (od hdd po fs). Vedu si své stránky na www.heronovo.cz.


  • Distribuce: Debian, CentOS, RHEL
  • Grafické prostředí: bash
  • Hodnocení autora: *

| blog