Pg+dSpam: zvyseni vykonu

[Jan Kasprzak]

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.

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

	OS je na tech internich SAS discich :-).

: > : 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?

	ordered. /proc/mounts rika toto:

rw,seclabel,relatime,barrier=1,stripe=512,data=ordered

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.

	Diky,

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
Please don't top post and in particular don't attach entire digests to your
mail or we'll all soon be using bittorrent to read the list.     --Alan Cox