Pg+dSpam: zvyseni vykonu

[Tomas Vondra]

On 13 Prosinec 2011, 11:27, Jan Kasprzak wrote:
> Tomas Vondra wrote:
> : Každopádně %util víceméně říká jaké procento bylo stráveno vyřizováním
> : requestů. U RAIDů je to pokud se nepletu tak že když má 2-diskový RAID0
> : 100% utilizaci, tak každý z disků bude mít 50%, protože 1/2 requestů
> půjde
> : na jeden disk, druhá 1/2 na druhý. Obdobně pro ta vaše RAID pole.
>
> 	Nikoliv. Pokud ma N-diskovy RAID 100 % utilizaci, muze to znamenat
> ze jeho fyzicke disky budou mit utilizace takove, ze jejich soucet
> bude _vetsi_ nebo roven 100 %. Utilizace 100 % znamena "v kazdem okamziku
> mel disk nevyrizeny aspon jeden pozadavek". No a protoze RAID (i disky
> s TCQ/NCQ) umi vyrizovat pozadavky paralelne, neznamena utilizace 100 %
> to, ze by RAID/disk pri zvyseni poctu pozadavku nemohl podavat jeste lepsi
> vykon.
>
> 	U md raidu je to videt pekne, protoze tam zaroven je videt i
> utilizace tech fyzickych disku. U HW raidu to nevidite. Cili kdyz vidim
> utilizaci logicke oblasti 100 %, ale fyzickych disku mensi, znamena to
> jen,
> ze system nedodava dostatecne paralelni pozadavky, a misto toho ceka
> na dokonceni nektereho z nich.
>
> 	To co mi prislo divne je, ze LVM/DM tu utilizaci pocita i k te
> logicke jednotce, zatimco MD nikoliv.

OK, zase jsem o něco chytřejší ;-)

> : Ve vašem případě bych zkusil použít tak 5GB (20% z poloviny RAM) a
> : uvidíte. Ale budete muset poštelovat pdflush aby vám to checkpoint
> nezabil
> : (/proc/sys/vm/dirty_background_ratio atd.).
>
> 	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

> 	Tyto dve posledni pomohly (vzdy jedna z nich - dokumentace rika
> ze jsou vzajemne vylucne, coz je logicke).
>
> 	Kdyz jsem dal synchronous_commit = off, tak to bezelo
> na maximalni propustnosti (psal jsem vedle).
>
> 	Pak jsem zkusil commit_delay = 50000 (pisou ze je to
> v mikrosekundach; nemyslim si ze by hodnota 100 necemu pomohla,
> kdyz pole jako celek dela tak max 1000 IOPS, a tedy jeden fsync
> musi trvat minimalne 10x tolik). To se projevilo tak, ze dSpam
> bezel v prumeru 10-20 sekund (pred zapocetim optimalizaci i 60-100 sekund)
> a utilizace disku byla jednotky procent, daleko mensi nez driv.

Ano, máte pravdu - je to v mikrosekundách, nechal jsem se zmást tím že
ostatní časy jsou vesměs v milisenkundách.

> 	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.

Navíc to hodně závisí na povaze zátěže a na hw, s tím že databáze může
používat několik různých diskových systémů (pro různé tablespacy), může to
být všelijak virtualizované apod.

> Reorganizaci disku udelat nemuzu, bezi tam jeste jine veci.
> Ale ano, o WAL na jinych discich jsem uvazoval, pokud neprijdu na nic
> jineho.

A nemůžete ty WAL zkusit šoupnout na systémový disk k OS? To obvykle
nebývá příliš vytížená část.

> : Pro další rady je potřeba několik informací:
> :
> : 1) jaká verze PostgreSQL to je?
> : 2) jaký je použit file systém?
>
> postgresql-8.4.7, ext4.

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?

Tomáš