Pg+dSpam: zvyseni vykonu

Úterý Prosinec 13 09:41:04 CET 2011

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.

	Dale jsem zkusil zvysit effective_io_concurrency = 10 (bylo 1 tusim),
ale nezda se, ze by to s utilizaci jednotlivych disku neco udelalo.

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

	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.

	Jeste jsem vcera podnikl pokus s diskama: puvodne byl Pg na
LVM, ktere bylo zretezenim sesti LUNu, z nichz kazdy byl HW RAID-1 ze
dvou SATA 7200 RPM disku (1 TB kazdy). Zkusil jsem uvolnit interni
disky v serveru a Pg presunout tam. Interni disky jsou 140 GB 15kRPM
SAS, spojene do 8-cestneho softwaroveho RAID-10. Na nich iostat ted vypada
takto:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               1.20   145.20   21.40  259.00   652.00   873.20    10.88     0.46    1.64   0.88  24.62
sdb               0.20   145.60   10.60  258.40   382.40   870.00     9.31     0.37    1.37   0.80  21.50
sdc               0.80   160.60   16.20  266.20   496.80   958.80    10.31     0.48    1.70   0.91  25.76
sdd               0.20   163.40    2.40  263.40   125.60   958.80     8.16     0.33    1.24   0.83  22.12
sde               1.00   148.20   17.40  259.40   579.20   884.40    10.58     0.41    1.48   0.85  23.56
sdf               0.00   151.00    5.00  256.60   196.80   884.40     8.27     0.32    1.22   0.82  21.40
sdg               1.20   141.60   11.80  258.80   536.00   855.60    10.29     0.41    1.53   0.90  24.30
sdh               0.20   144.00    5.80  256.40   285.60   855.60     8.70     0.28    1.06   0.67  17.62
md2               0.00     0.00   95.40 1075.20  3254.40  3559.20    11.64     0.00    0.00   0.00   0.00

Je zajimave ze utilizace toho samotneho md je nulova - mozna je to tim,
ze device mapper pocita jinak ty requesty predane fyzickym diskum?
Kazdopadne ale trva to, ze utilizace tech fyzickych disku je relativne
mala - zadny se ani zdaleka neblizi 100 procentum. Taky pocet iops nevzrostl
nijak zavratne (ostatne slo o zmenu sesti nezavislych spindles za v podstate
ctyri rychlejsi).

: 
: -- 
: Zito
: _______________________________________________
: Linux mailing list
: Linux na linux.cz
: http://www.linux.cz/mailman/listinfo/linux

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