optimalizace PostgreSQL a systemu

[Chlopcik Ales]

"news.volny.cz" wrote:
> 
> Ing. Pavel PaJaSoft Janoušek wrote:
> 
> > news.volny.cz <mailto:oldfrog na volny.cz> wrote:
> >
> >>Vzorovy dotaz vytizi postgres process CPU na 100%. Potreboval bych
> >
> >       Promiňtě, ale každý dotaz je schopen vytížit CPU na 100% pokud se má
> > flákat a je třeba vykonat požadovanou práci (navíc ten počet řádků již není
> > "malý"). Otázka nezní, proč se procesor vytížil na 100% (to je věc vcelku
> > normální), otázka stojí spíše na jakou dobu a zda-li tuto dobu nelze
> > podstatně zkrátit (ať už hrubou silou = silnější železo, rychlejší disky,
> > více RAM apod., tak optimalizaci datového modelu nebo dotazování).
> 
> Rozumim, co chcete rici. Myslim ale, ze je rozdil mezi tim, zda tech
> 100% zabere system nebo userspace a cim. Vidim process postgres, ktery
> zabira processor a ted bych prave - ve shode s tim, co rikate Vy -
> potreboval jit niz a zjistit vice o tom vytizeni. Bohuzel o tematu vim
> dost malo, no vzdycky je neco poprve :) Zabral by postgres 100% i kdyz
> by se vetsinu casu cetlo z disku??
> 
> >       Pro začátek bych začal s příkazem EXPLAIN a EXPLAIN ANALYZE -
> > zjistíte třeba že je vhodné doplnit nějaké indexy (dump databáze sice bude
> > stále stejný - pár řádků ve výpisunepoznáte, ale na disku to může být
> > podstatný rozdíl a ve výkonu až diametrálně odlišný) nebo že máte pomalé
> > disky apod...:-)
> 
> Zkusim tedy ten vnoreny subselect najak analyzovat a nechat si
> nednotlive casti vysvetlit... Hmm, muzete doporucit nejaky sql
> beautifier? Ten dotaz ma 712 slov.
> 
> --
> ===============
> --- OldFrog ---
> ===============

	DDV

	Samozrejme, ze pokud dotaz _prosiva_ 20 mega dat, tak na systemu, ktery
ma 8 mega RAM TO mozna pujde, ale rozhodne nepobezi. Tim m.j. narazim na
TO, ze jste nesdelil Vasi RAM, CPU, ...

	Kdyz uz TO budete cist, tak se zamerte na komparaci architektury dotazu
a architektury databaze. Cesky receno, zda na vsechny (hlavni) polozky
ve WHERE existuji indexy, a to ve vsech (dotcenych) tabulkach (v jedne
nestaci). Indexy, indexy, indexy a kdyz TO nestaci, tak indexy.
	Jak uz jsme (nejen ja :-) tady nekolikkrat konstatovali. Podstatneho
snizeni odezvy lze dosahnout :
		- preformulaci odtazu
		- indexaci polozek

	Mnou :-) odhadovany podil na zlepseni _vykonnosti_ databaze
optimalizaci :
		- aplikace cca 60 procent
		- databaze (indexy) cca 35 procent
		- systemu cca zbytecek

	Krome relativne _beznych_ nastroju (TORA, PgAdminIII, ...) a jejich
procentualnich _statistik_ o nicem lepsim nevim.
	Nejmocnejsi nastroj je hlava s podporou SqlExplain.

	IMHO (ale dotaz a strukturu jsem nevidel, takze TO berte s obrovskou
rezervou :-) : Pokud ma dotaz 712 slov (pokud TO nejsou BYTE :-), tak TO
vypada budto na prilis komplikovany problem nebo na podhodnoceny navrh
struktury baze.
	300 MB dat v milionu zaznamu, t.j. 300 BYTE v zaznamu a selekt pres
celou stranku ??? TO aby TO byly jednobitove polozky.

	Napada mne jeste asi tak tisic zpusobu, jak se TO da domrsit (napr.
typove konverze, ... :-). Kdyz, tak privatne.

	Ales