Pg+dSpam: zvyseni vykonu

Úterý Prosinec 13 10:56:12 CET 2011

On 13 Prosinec 2011, 9:41, Jan Kasprzak wrote:
> Václav Ovsík wrote:
> : On Mon, Dec 12, 2011 at 10:10:26PM +0100, Jan Kasprzak wrote:
> : > ...
> : >
> : > Podle iostatu je temer ke 100 % vytizeny filesystem, na kterem ma
> : > dspam a postgresql sva data.
> : >
> : > Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s
> avgrq-sz avgqu-sz   await  svctm  %util
> : > sdi               0.00   290.40   10.00  311.40   136.80  1495.20
> 10.16     3.15    9.79   1.47  47.36
> : > sdj               0.00   279.20   11.00  314.80   191.20  1464.00
> 10.16     2.53    7.75   1.27  41.22
> : > sdk               0.20   292.20   11.00  322.00   212.00  1544.80
> 10.55     1.32    3.97   0.69  23.04
> : > sdl               0.20   291.80    8.00  322.40   148.00  1573.60
> 10.42     3.03    9.66   1.48  49.02
> : > sdn               0.00   284.00    7.60  320.80   136.00  1524.80
> 10.11     2.07    6.49   1.63  53.58
> : > sdm               0.00   294.60    7.40  327.60    87.20  1576.80
> 9.93     2.35    7.03   1.36  45.66
> : > dm-1              0.00     0.00   55.60 2509.60   912.00  9135.20
> 7.83    29.78   12.06   0.38  96.88
> : >
> : > dm-1 je prokladany LV nad sdi-sdm, coz jsou HW RAID-1 LUNy.
> : >
> : > A ted je otazka, jestli jde nejak rict postgresu, aby delal zapisy
> nejak
> : > "inteligentneji", aby nepotreboval tolik zapisovych operaci za
> jednotku casu.
> : > Nebo vubec nejak nastavit parametry Postgresu.
> : >
> : > Mate k tomu nejake tipy?
> :
> : Máte poštelovaný PostgeSQL? Třeba dle
> : http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
> :
> : Výchozí nastavení Pg není vhodné pro produkční nasazení. Jeho výchozí
> : parametry jsou nastaveny tak, aby mu stačilo málo zdrojů, ale samozřejmě
> : není schopen dodat výkon.
>
> 	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).
Další věc která se zapisuje na disk jsou buffery (shared buffers), což se
děje primárně při checkpointu ale může k tomu docházet i jindy (např.
pokud modifikujete tak velkou část databáze že v shared buffers není dost
místa).

Zápisy do WAL jsou sekvenční (prostě se zapisuje na konec souboru) a i
obyčejný disk zvládne zápis několika desítek MB/s. Problém je že zbytek
zápisů (do data filů) je náhodný, což samozřejmě ovlivňuje zápis do WAL.

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.

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

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

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

>
> 	Analyze se pousti kazdou noc, v tom problem neni.
> Jeste teda k shared_buffers: ja jsem to vcera zkusil zvysit, ale jak
> daleko
> je mozne jit? Ten stroj ma 64 GB RAM, pricemz rekneme tak polovinu bych
> potreboval zachovat pro jine ucely. Zvysil jsem buffery na 256 MB, pricemz
> jsem kvuli tomu jeste musel zvysovat kernel.shmmax. Samotna databaze
> dSpamu (du -sk na adresar pgsql/data) zabira ted neco pod 63 GB.

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

Zrovna o tomhle jsem minulý měsíc měl přednášku na CSPUGu - viz.

http://www.slideshare.net/fuzzycz/checkpoint-cspug-22112011

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)

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.

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)? Případně lze zauvažovat o
nasazení SSD pro datové soubory - bude to levnější než ta hromada SAS
disků.

Pro další rady je potřeba několik informací:

1) jaká verze PostgreSQL to je?
2) jaký je použit file systém?

Tomáš