Pg+dSpam: zvyseni vykonu

Jan Kasprzak kas na fi.muni.cz
Středa Prosinec 14 05:18:28 CET 2011


Pavel Kankovsky wrote:
: On Wed, 14 Dec 2011, Jan Kasprzak wrote:
: 
: > Zasumene to je, ale ne az tak moc - je evidentni, ze pri snizovani
: > (a prekvapive i zvysovani) delay se casy zhorsuji.
: 
: Jedno možné vysvětlení je, že pro jeden dopis provádí commit tolikrát, že
: se tam ty prodlevy akumulují. Tomu by odpovídalo, že nekde od delay=12500
: se čas prodlužuje víceméně lineárně vůči delayi.
: 
: Pokud je to pravda (a dřívější zmínky o autocommitu by tomu nasvědčovaly),
: tak to znamená, že tohle je to úzké místo a že je potřeba vzít cluestick a
: pořádně s ním někomu namlátit. :)

	Ano, premyslel jsem o tom co by se stalo, kdybych to cele obalil
do jedne transakce - nemel by to byt slozity patch.

	 Stalo by se to, ze by velmi pravdepodobne velmi brzo
a casto dochazelo k deadlockum v pripade, kdy dve instance dspamu budou
aktualizovat hit county u tech stejnych tokenu, ale sahnou na ne
v opacnem poradi. Muselo by se na tohle myslet, coz zase nevim jestli
na urovni storage backendu dSpamu jeste jde. On ten dSpam totiz pouziva
databazi jen jako dost neinteligentni uloziste dat.

	A to jeste nemluvim o tom, ze treba v Oracle se mi takto zamykala
databaze pri paralelnich updatech, kde ty transakce ani nesahaly na tentyz
radek, ale na radek s ID o jedno vedle (pravdepodobne to zamykalo
na urovni bloku, ne radku). A to pak pri navrhu aplikace vubec nejde
s necim takovym pocitat.

	Tak jsem ten cluebat zase schoval.

-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


Další informace o konferenci Linux