Pg+dSpam: zvyseni vykonu

[Tomas Vondra]

On 13 Prosinec 2011, 17:11, Jan Kasprzak wrote:
> Tomas Vondra wrote:
> : To je otázka na kterou neexistuje jednoznačná odpověď - ladění
> checkpointu
> : je o hledání kompromisu mezi latencí a propustností. Na jednom konci je
> : systém s nízkou latencí, tj. průběžně odpovídající klientům, na druhém
> : konci je systém celkový průměrný tps je o něco vyšší ale latence hodně
> : skáče a může být i několik minut "mrtvý" protože došlo k checkpointu a
> na
> : disk se tlačí hrozně moc dat. Osobně jsem příznivcem první varianty,
> pokud
> : s tím nějak (byť) minimálně interagují uživatelé (např. chtějí
> : odesílat/přijímat poštu).
>
> 	Ja si prave myslim ze to neni takto jednoznacne - jsou oblasti,
> kde posunutim jednoho parametru se zlepsuje jak latence, tak propustnost.
> To byl ten muj problem, kdy kvuli okamzitemu fsync() po kazde transakci
> se beh dspamu natahl na minuty na jeden mail. A muj nazor je, ze casto
> je primo videt ze je neco spatne, a pak by takove chovani nemelo byt
> implicitni.

Ano, není to jednoznačné - a to je právě ten problém :-( Ale jak říkám,
možná někdo přijde s použitelnou heuristikou a v další verzi to bude v
core.

> 	Provedl jsem nejaka mereni, jak se ten opozdeny commit
> projevi na vykonu systemu. Jsou to hruba data, ktera jsou jeste navic
> ovlivnena tim, pro ktere uzivatele zrovna chodily maily (prazdna/plna
> databaze dSpamu pro toho uzivatele), a kolik jich chodilo zaroven.
> Urcite to bude zatizeno velkym sumem, nicmene neco z toho videt je:
>
> 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
>
> Jednotliva pole na radku jsou:
> zacatek mereni (a konec predchoziho mereni), commit_delay,
> commit_siblings,
> pocet mailu zpracovanych dSpamem v teto periode,
> median doby zpracovani (50 % pripadu ma stejny nebo lepsi cas),
> 3. kvartil doby zpracovani (75 % pripadu ma stejny nebo lepsi cas),
> 9. decil doby zpracovani (90 % --""--),
> 99. percentil doby zpracovani (99 % --""--)
>
> Nakonec jsem vyhodnotil ze optimalni parametr bude nekde okolo 1500 us,
> a pro kontrolu jsem provedl jeste jedno mereni s touto hodnotou abych
> zjistil, jak moc se bude lisit od drive provedeneho mereni.

OK, akorát mi není jasné v jakých jednotkách ty časy jsou. Vteřiny nebo ms?

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.

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

T.