Pg+dSpam: zvyseni vykonu

[Jan Kasprzak]

Tomas Vondra wrote:
: On 13 Prosinec 2011, 13:02, Jan Kasprzak wrote:
: > : > 	Hmm, nemel by si Postgres tohle merit sam? Jakoze pokud vidi
: > : > ze fsync() na WAL mu zabere v prumeru treba 10 ms, tak si sam rict,
: > : > ze commit_delay = 10000 nicemu neublizi a pomuze propustnosti?
: > : > Idealne kdyby si to pocital podle aktualni zateze disku sam.
: > :
: > : To je poměrně problematické - je to obchod "propustnost za latenci" a to
: > : nelze rozhodnout na úrovni SW, to musí udělat uživatel. Resp. například
: > já
: > : nechci aby za mne toto rozhodnutí dělala databáze.
: >
: > 	Tak ja si myslim ze pokud konzistentne ceka na fsync toho WAL,
: > tak by si mohl odhadnout ze uzke misto je tam, a tedy ma cenu priste
: > par milisekund pockat. Jasne ze to nemuze byt takto natvrdo, ale
: > nakolik tomu rozumim (asi moc ne), mam pocit, ze tohle neni cislo ktere
: > by melo byt vzdycky stejne, i kdyz se meni zatez. Oni se tomu trochu
: > snazi napomoct temi siblings, ale to je asi jen takova heuristika.
: 
: Jasně, ale je to hodně vágní formulace a přístup core týmu je takový že
: pokud něco nelze implementovat tak aby to části prokazatelně pomohlo a
: zbytku neškodilo, tak se to nechá jako vypnuté.

	Ono by taky stacilo (zvlast v pripade dSpamu, ktery bezi
podle vseho v AutoCommitu) neodhadovat ty siblings, ktere muzou patrit
kdovijakym dlouhodobym transakcim, ale divat se zejmena na ty autocommity,
protoze tam vime, ze se je snazime vyridit co HW da, a vime, ze nebudeme
cekat na klienta.

	Nebo odhadovat kolik casu tahle transakce zatim stravila cekanim
na I/O (ne na klienta) a dovolit si treba jeste 20 % z toho pockat s tim fsync.
Nebo zjistovat kolik % casu cekani cele databaze na I/O jsou bezne
I/O operace, a kolik % casu je fsync(). A chovat se tak, aby ten fsync()
nebyl vetsina cekani.

	Ale mozna je tam fakt jeste nejaky dalsi problem ktery ted nevidim.
Jen tak strilim od boku.

: > 	ordered. /proc/mounts rika toto:
: >
: > rw,seclabel,relatime,barrier=1,stripe=512,data=ordered
: 
: Potřebujete tam relatime? Nestačil by noatime? I když je to pořád lepší
: než nic.

	Jasne ze potrebuju, atime je jeden ze zakladnich debugovacich nastroju.
Ale i tak, atime jsou asynchronni zapisy. Az budou vsechny disky vytizene
na 100 %, budu resit atime. Ted jsou vytizene na 20-30 % a ceka se na jeden
fsync().

: > OK, zda se ze problem je tedy vyresen aspon castecne. V nebezpeci
: > zapnu synchronous_commit=off. Jeste snad posledni dotaz: kdy se ktere
: > volby nactou z toho konfiguracniho souboru? U nekterych je tam explicitne
: > psano "requires restart". Znamena to, ze ty ostatni se projevi
: > ihned/brzo/jen
: > pro nove backendy/... ? Konkretne bych ted chtel delat pokusy s tim
: > commit_delay a commit_siblings.
: 
: Ne, musíte poslat SIGHUP. Obecně volby které ovlivňují velikost paměti
: (shared  buffers, wal buffers, počet connections etc.) vyžadují restart,
: zbytek stačí SIGHUP.

	SIGHUP vsem backendum nebo jen postmasterovi? Jde mi hlavne o to,
abych mohl provadet mereni, a vedel jiste, ze vsichni uz pouzivaji novou
konfiguraci.

	Jeste teda zpatky k tem checkpointum: neni to naopak tak, ze ja
vlastne chci at databaze zapisuje jen do WAL, pokud to jde (sekvencne, rychle,
hodne transakci) a az to fakt nejde jinak, tak naraz at zapisuje do datafilu,
pricemz necha OS at si ty pozadavky setridi jak chce, a tim vytizi disky
na 100 %? A nevadi mi, ze dSpam jednou za 5 minut pobezi minutu, pokud
toho celkove zvladnu 5x tolik.

-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