Vlákno názorů k článku Používání indexů v PostgreSQL: krátce a pro začátečníky od Paja - I kdyz sem se snazil projit vsechny vygooglene...
-
Paja (neregistrovaný)
I kdyz sem se snazil projit vsechny vygooglene helpy k nastaveni pameti, porad mi chybi nejake spolehlive doporuceni k nastaveni postgresu.
Konkretne: server ma 24GB RAM, je dedikovany jen pro databaze (cca 8GB zapakovany postgres, + test server tohotez + cca 6GB zabaleny firebird). Dale ma radic s 1GB NV RAM a disky jsou 15k rmp SAS v raid 5. Pro produkcni postgres muzu uvazovat s cca cistych 12GB RAM. Zapisuje se 5-10k transakci denne. Pri zapisu se trigery overuje konzizstence a omezeni (napr. zaverka skladu). Aktualne nema server vykonnovy problem.To ze ma server relativne dost RAM vzhledem k velikosti DB a ze ma radic s 1GB NVRAM mi trochu boura predstavu o kvalite vygooglenych dporuceni.
A ani netusim, z ceho vychazet pri konfiguraci.Pak mam jednu poznamku k ruseni a obnovovani indexu pri vytvareni reportu. Osvedcilo se mi v nekterych pripadech vytvoreni temp tabulky. Oproti vypoctu napr. procentualni dostupnosti top 100 produktu na prodejnach s indexy a temp tabulkou se to zrychlilo 20x.
-
Sice RAID5 je asi to nejhorší, co můžete udělat, ale vzhledem k dostatku RAM a minimu transakci to musí zvládat v pohodě - konfigurace pg - např. zde http://postgres.cz/wiki/Desatero#P.C5.99id.C4.9Blte_PostgreSQL_dostatek_pam.C4.9Bti
Optimalizace dotazů je občas alchymie - a to včetně dočasných tabulek - na jednu stranu jsou docela drahé - na druhou stranu pokud vám ustřelují statistiky, tak dočasná tabulka může "přerušit chybu" v aplikaci statistik a šíření chyby a tudíž planer může vygenerovat skutečně optimální plán - případně i nad dočasnou tabulkou je možné vytvořit indexy a zase o něco zrychlit provedení dotazu.
-
V situaci kdy databáze sdílí železo s dalšími neznámými aplikacemi, těžko nějak radit. Ne úplně jsem pochopil co se myslí tím "zapakovaným postgresem" a "zabaleným firebirdem"?
Každopádně standardní doporučení zní shared_buffers = 1/4 dostupné paměti, takže pokud 12 GB zabírají jiné aplikace tak nastavte plus minus 2 až 3GB shared. Také mi není jasné jak z toho plyne velikost databáze, nicméně ona je spíš důležitá velikost aktivní části té DB (s kolika MB/GB se skutečně aktivně pracuje).
Co znamená 10k transakcí za den? Jak ty transakce vypadají? Pokud jsou to malé transakce (insert pár záznamů, pár updatů a deletů) tak 10k / den je pod hranicí šumu, zejména když tam máte řadič s 1GB write cache. Ale pokud to jsou nějaké velké bulk operace tak vám ani ten 1GB nemusí stačit - RAID5 je obecně asi nejhorší RAID varianta pro zápis.
-
Paja (neregistrovaný)
Premyslel jsem nad tim. Je pravda, ze od doby porizeni serveru pred dvema lety mame asi pul roku novy aplikacni server, kde jsem zvirtualizoval vsechny ostatni servery krome tohodle databazoveho. Testovaci databazi i ucetni firebird presunu na ten aplikacni. Z RAID 5 udelam RAID 10 (jsou tam 4ks 15krpm 2,5" 146GB, coz bude kapacitne stacit s velkou rezervou). Drive tam behal napr. i virtualni 2008 server. Takze budu mit celych 24GB pro primarni databazi a zadne jine aplikace tam nebudou.
Tim zabalenym jsem myslel cista komprimovana data. S indexy ma ta primarni databaze 22GB. Nejvic zabiraj soubory (7G) ale s temi se nepracuje. Dalsi jsou skladove pohyby (3,5GB) - tam se saha furt. Treti je materializovane view - datova kostka pro obchodniky (3GB) s tou se taky pracuje intenzivne.
Temi transakcemi myslim zapis obchodni transakce. Typicky hlavicka dokladu, radek dokladu, rozpad na skladove pohyby, zmena skladove karty vcetne kontroly konzistence, podnet k prepocitani datove kostky a prenosu zmen na web. Takovato transakce trva cca 100ms. Jenze kdyz jich prijde 10 najednou, uz to ty ostatni brzdi. Ne ze by si toho bezny uzivatel vsimnul. Jen si myslim, ze nerozumim uplne nastaveni pameti a nastavit to jen od oka je ma neschopnost. Treba by se trivialnim nastavenim pameti dala zvysit propustnost. Nechci to resit az to bude potreba resit. Je pravda, ze z hlediska prumerneho zatizeni je to pod hranici sumu.
Nektere view pracuji se znacnym objemem dat. Sice je pouziva velmi mala cast firmy a je to porad rychlejsi, nez jine systemy se kterymi sem mel moznost pracovat, nicmene pokud by nastaveni pameti urychlilo slozitejsi view, tak to tak rad nastavim. Jenze netusim jak.
Slozitejsi transakce (prevod mezi centralnim skladem a pobockami o nekolika tisicich radcich) dela jen par lidi. Takze jestli to zapisuje 30 sec, nebo 2 sec je skoro jedno - kdyz to delaj jednou denne.Zkusim prostudovat ty doporuceni. Jenze zatim jsem vzdy jen nasel doporuceni ale nevim proc to nekdo takto doporucuje.
PS: dik za komentar (i komentar autora clanku), bez nej bych se asi k predelani serveru nedokopal
