Pg+dSpam: zvyseni vykonu

[Tomas Vondra]

On 13 Prosinec 2011, 13:02, Jan Kasprzak wrote:
> Tomas Vondra wrote:
> : On 13 Prosinec 2011, 11:27, Jan Kasprzak wrote:
> : > 	Jak poznam ze by nastala tato situace? Kde vidim ze probiha
> : > checkpoint?
> :
> : To že probíhá checkpoint poznáte z logu PostgreSQL, pokud zapnete
> : log_checkpoints=on, vypisuje to tam podrobněji kolik dat se zapsalo, jak
> : dlouho to trvalo a jak dlouho trval závěrečný fsync.
> :
> : Případně je checkpoint vidět i z "ps" výstupu, ale bez statistik.
> :
> : To že nastává problém s checkpointem poznáte tak že začne checkpoint,
> : chvíli se nic neděje a pak najednou nastane peklo na zemi - disky se
> točí,
> : nestíhají, iowait roste apod. Problém je v tom že databáze zapisuje
> změny
> : ze shared buffers do page cache, tam se to štosuje a systém se najednou
> : rozhodne že teda vlastně dosáhl dirty_background_ratio a začne to tlačit
> : na disk. Následně se dosáhne dirty_ratio, systém "vypne" page cache pro
> : zápis a procesy musí zapisovat přímo na disk. Pokud jsou ty hodnoty moc
> : velké (klidně to může odpovídat pár GB), problém je zaručený.
> :
> : Podrobněji např. viz.
> : http://www.westnet.com/~gsmith/content/linux-pdflush.htm
>
> 	Jo, OK. Ale tohle neni muj problem. V zasade mi nevadi, kdyz
> jednou za 5 minut ten system nebude delat nic jineho nez zapisovat
> buffery.
> Pokud je bude zapisovat tak ze vsechny disky vytizi na 100 %, at si
> zapisuje.
>
> : > 	Hmm, nemel by si Postgres tohle merit sam? Jakoze pokud vidi
> : > ze fsync() na WAL mu zabere v prumeru treba 10 ms, tak si sam rict,
> : > ze commit_delay = 10000 nicemu neublizi a pomuze propustnosti?
> : > Idealne kdyby si to pocital podle aktualni zateze disku sam.
> :
> : To je poměrně problematické - je to obchod "propustnost za latenci" a to
> : nelze rozhodnout na úrovni SW, to musí udělat uživatel. Resp. například
> já
> : nechci aby za mne toto rozhodnutí dělala databáze.
>
> 	Tak ja si myslim ze pokud konzistentne ceka na fsync toho WAL,
> tak by si mohl odhadnout ze uzke misto je tam, a tedy ma cenu priste
> par milisekund pockat. Jasne ze to nemuze byt takto natvrdo, ale
> nakolik tomu rozumim (asi moc ne), mam pocit, ze tohle neni cislo ktere
> by melo byt vzdycky stejne, i kdyz se meni zatez. Oni se tomu trochu
> snazi napomoct temi siblings, ale to je asi jen takova heuristika.

Jasně, ale je to hodně vágní formulace a přístup core týmu je takový že
pokud něco nelze implementovat tak aby to části prokazatelně pomohlo a
zbytku neškodilo, tak se to nechá jako vypnuté.

Osobně už jsem si systémů které se snaží být chytřejší než já užil dost,
ale nevylučuji že se nějaká taková heuristika neobjeví. Každopádně
kombinace delay+siblings to umožňuje poměrně dobře ladit pro konkrétní
systém.

> : OK, to zní rozumně, i když jste 3 minor verze pozadu. Trochu jsem se bál
> : že tam bude ext3, což z pohledu fsyncu není zrovna optimální. Ale ext4
> se
> : chová velmi rozumně, zhruba na úrovni xfs. V jakém módu to je připojené?
> : Writeback, ordered nebo journal?
>
> 	ordered. /proc/mounts rika toto:
>
> rw,seclabel,relatime,barrier=1,stripe=512,data=ordered

Potřebujete tam relatime? Nestačil by noatime? I když je to pořád lepší
než nic.

> OK, zda se ze problem je tedy vyresen aspon castecne. V nebezpeci
> zapnu synchronous_commit=off. Jeste snad posledni dotaz: kdy se ktere
> volby nactou z toho konfiguracniho souboru? U nekterych je tam explicitne
> psano "requires restart". Znamena to, ze ty ostatni se projevi
> ihned/brzo/jen
> pro nove backendy/... ? Konkretne bych ted chtel delat pokusy s tim
> commit_delay a commit_siblings.

Ne, musíte poslat SIGHUP. Obecně volby které ovlivňují velikost paměti
(shared  buffers, wal buffers, počet connections etc.) vyžadují restart,
zbytek stačí SIGHUP.

Tomáš