Pg+dSpam: zvyseni vykonu

[Jan Kasprzak]

Tomas Vondra wrote:
: On 13 Prosinec 2011, 17:11, Jan Kasprzak wrote:
: > Dec 13 14:32:00 delay=100000 siblings=5 421 16.81 29.28 31.93 72.16
: > Dec 13 14:38:30 delay=50000 siblings=5 1263 9.54 13.19 21.94 57.90
: > Dec 13 14:54:00 delay=25000 siblings=5 1236 5.40 7.57 11.97 29.13
: > Dec 13 15:02:30 delay=12500 siblings=5 494 2.86 5.57 7.89 17.81
: > Dec 13 15:13:30 delay=6125 siblings=5 502 2.50 4.33 7.33 16.07
: > Dec 13 15:24:00 delay=3062 siblings=5 634 2.77 4.12 5.83 12.07
: > Dec 13 15:33:00 delay=1531 siblings=5 283 2.02 3.40 4.86 14.54
: > Dec 13 15:41:00 delay=766 siblings=5 583 2.45 4.13 6.02 13.33
: > Dec 13 15:54:30 delay=383 siblings=5 446 2.76 4.08 6.72 11.48
: > Dec 13 16:03:00 delay=192 siblings=5 605 3.72 5.95 9.49 20.85
: > Dec 13 16:11:00 delay=96 siblings=5 436 3.62 5.82 10.61 15.98
: > Dec 13 16:19:00 delay=48 siblings=5 1539 7.37 8.93 18.18 34.14
: > Dec 13 16:29:00 delay=24 siblings=5 597 6.30 11.47 20.87 36.57
: > Dec 13 16:37:00 delay=0 siblings=X 612 7.66 16.55 25.32 40.08
: > Dec 13 16:47:00 delay=1500 siblings=5 460 2.63 4.29 7.59 16.02
: > Dec 13 16:57:00 konec
: >
: OK, akorát mi není jasné v jakých jednotkách ty časy jsou. Vteřiny nebo ms?

	Vteriny. Omlouvam se, ze jsem to neuvedl.

: Každopádně to bude zašumněné - jednak na tom serveru asi běží něco
: dalšího, zadruhé počet mailů má přímý vliv na objem dat který je třeba
: zapsat během checkpointu (a není jasné v kterých měřeních checkpoint byl a
: ve kterých ne) apod.

	Ja pevne doufam ze checkpointy se na tom az tak neprojevily
(maximalne to, jestli v merenem intervalu byl jeden nebo dva).
Zasumene to je, ale ne az tak moc - je evidentni, ze pri snizovani
(a prekvapive i zvysovani) delay se casy zhorsuji.

: Přijde mi že v tomto konkrétním případě se hodně těží z toho že všechny ty
: connections jsou velmi aktivní a transakce jsou velmi krátké (i díky tomu
: autocommitu).

	Ja myslim ze prave nejsou az tak aktivni - dSpam nevyuziva ani vsechna
dostupna spojeni, a ani po celou dobu nebyla fronta mailu plna. Tohleto
je spis test latence nez propustnosti. A je videt, ze bez delay commitu
je latence daleko horsi nez s rozumnym delay.

	Ja mam pocit, ze bez tech delay funguje Pg tak, ze zapise transakci
do WAL, zavola fsync(), zapise dalsi transakci, zavola fsync(), atd.
Coz zpusobuje nevytizeni disku, nehlede na to, ze se ceka na fsync() i
v pripade, kdy se zapisuji drive commitnuta data do tablespacu, a ted disky
jsou primarne vytizene necim jinym nez tim fsync(). Podle me benefit tech
opozdenych commitu je, ze se fsync() vola mene casto, a tedy OS ma vic prostoru
pro preusporadavani diskovych operaci. Pak to zrejme probiha tak, ze Pg
zapise transakci do WAL, zavola fsync(), a nez to fsync dobehne, ziska Pg
nekolik dalsich commitu, ktere _najednou_ zapise do WAL (a mozna jeste
necha trochu prostoru pro zapis drive commitnutych dat do tablespacu),
a az _potom_ zavola dalsi fsync(). Pak vyhrava i latence, i propustnost.

	At se na to divam jak chci, pripada mi fsync() po kazdem commitu
bez cekani jako totalni nesmysl. Ale mozna to Pg nedela az tak spatne
jak si myslim.

-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