Pg+dSpam: zvyseni vykonu

[Jan Kasprzak]

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.

	Co se tyce posty, tak uzivatelum je jedno jestli se mail doruci
do pul minuty nebo do peti minut. Jedine kdy uzivatel fakt chce odezvu je,
kdyz chce rict dspamu "tento mail byl klasifikovany spatne" a pak si hned
overit, jestli podobny mail uz priste bude klasifikovany dobre. Jinak
je vsechno off-line provoz.

	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.

Ten pocet mailu je jen pro predstavu z jakeho vzorku cinime zavery,
neni to mira propustnosti (v systemu v te dobe nebyla nejaka vetsi fronta
mailu cekajicich na zpracovani).

Intuitivne bych rekl, ze konzervativnejsi nastaveni (s rozumnejsim chovanim
i pri vetsi zatezi) bude to s delsim delay. Cili v pripade problemu
to hodlam zvysovat az nekam k tem 5-10 ms.

	Toz tak, diky vsem za napady. Zda se, ze ted to nejak funguje.

-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