Pg+dSpam: zvyseni vykonu

Úterý Prosinec 13 11:27:54 CET 2011

Tomas Vondra wrote:
: On 13 Prosinec 2011, 9:41, Jan Kasprzak wrote:
: > 	No, jeste je divne, ze to ceka na disk tak, ze utilizace
: > toho LV je cca 100 %, ale pritom utilizace jednotlivych disku neni tak
: > velka.
: > Je mozne ze by treba cekal na fsync() a pritom nezvladal delat nic jineho?
: > Na strance kterou odkazujete jeste radi zvysit checkpoint_segments.
: > To ted zkusim.
: 
: Ano, při každém commitu se na disk musí fsyncnout transakční log (WAL).

	Jo, tohle samozrejme vim. To co mi prislo divne se tyka tohoto:

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

: > 	Dale jsem zkusil zvysit effective_io_concurrency = 10 (bylo 1 tusim),
: > ale nezda se, ze by to s utilizaci jednotlivych disku neco udelalo.
: 
: Teď se možná pletu, ale tohle se myslím používá jenom u bitmap index
: scanů, takže žádný efekt pozorovat nemusíte. Navíc to závisí na
: posix_fadvise, takže to je závislé na systému. Ale víc o tom nevím.

	OK, diky za vysvetleni.

: > : Jakmile poladíte sdílenou paměť, buffery atd a budou aktuální statistiky
: > : ANALYZE, můžete začít logovat pomalé dotazy (log_min_duration_statement)
: > : a zkoumat jestli nechybí nějaký index atd.
: 
: Je samozřejmě možné že tam někde chybí index, ale to by způsobovalo nárůst
: "r/s" (protože DB by musela hledat data jinak), zatím co vy máte problém s
: "w/s". Takže tím to podle mne nebude.

	Jo. Nemyslim si, ze by dSpam mel spatne navrzene schema (s chybejicim
indexem) a ze ja bych byl prvni kdo na to narazil.

: Analyze se pouští automaticky na základě modifikací tabulek (pokud máte
: dostatečně novou verzi a zapnutý autovacuum).

	Ja poustim analyze rucne kazdou noc, spolu s promazavanim tokenu
dSpamu. To je doba kdy se v databazi dela naraz hodne zmen, a tedy ma
cenu po nich pustit analyze.

: Obecně se doporučuje dát do shared buffers zhruba 20% paměti a pak s tím
: případně hýbat a sledovat jestli to pomůže nebo ne (většinou to výkon
: nezvyšuje, spíš naopak). O cachování pro čtení se stejně stará page cache.
: 
: 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?

: Zrovna o tomhle jsem minulý měsíc měl přednášku na CSPUGu - viz.
: 
: http://www.slideshare.net/fuzzycz/checkpoint-cspug-22112011

	Diky, podivam se.

: Každopádně pro začátek můžete zkusit toto:
: 
:  * shared_buffers = 5GB
:  * wal_buffers = 16MB
:  * checkpoint_segments = 64
:  * checkpoint_completion_target = 0.9
:  * checkpoint_timeout = 30m
:  * log_checkpoints = on
: 
: případně můžete zkusit ještě toto
: 
:  * synchronous_commit = on (výkon vs. durability)
:  * commit_delay = 100 (propustnost vs. latence)

	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.

	Tak jsem zkusil commit_delay = 10000 a commit_siblings snizit na 2,
coz zpusobuje ze dSpam bezi tak 1-5 sekund, coz povazuji za unosne.
Z tohoto soudim, ze dSpam bezi v AutoCommit rezimu a to cekani ho zpomaluje.
Tuhle volbu jsem nemel moznost zatim vyzkouset poradne, protoze se mi mezitim
vsechny maily z fronty rozposilaly :-)

	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.

: Případně můžete zkusit oddělit WAL a datové soubory na různé disky (např.
: WAL na jeden 2-diskový RAID1), tak aby se nemíchalo náhodné a sekvenční
: I/O.

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

: Ne všechno lze zvládnout na sw úrovni - co RAID řadič s write cache (psal
: jste že tam máte HW raid, ale zřejmě bez cache)?

Je tam cache, ale ne moc velka - musel bych se podivat. HW RAID pole
je SGI IS-300 (coz je nejake rebrandovane LSI-logic).

: Případně lze zauvažovat o
: nasazení SSD pro datové soubory - bude to levnější než ta hromada SAS
: disků.

	Jo, akorat tu hromadu SAS disku uz mam :-)

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

-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