DB Server a SSD disky

[Dalibor Toman]

DD,

On Thursday, April 08, 2010 10:58 AM ,
Vladimir Macek <macek na sandbox.cz> wrote:


diky za podnety (nektere optimalizace tohoto typu jsme jiz provedli). 
Ale u nas zadani nezni: 'potrebujeme zrychlit databazi' ale 'budeme 
mit nove zelezo - co takhle koupit misto tocivych disku netocive?'.

Diky
D. Toman

>> On 8.4.2010 09:35, Dalibor Toman wrote:
>>> premyslime o upgrade DB serveru (postgres, DB na disku zabira cca
>>> 80GB, slouzi i jako uloziste namerenych dat - cili zapisu je 
>>> dost).
>>> Jednou z variant, jak zvednout vykon je...
>>
>> Na vasem miste bych nejdrive provedl nasledujici kroky k overeni, 
>> ze
>> postgres neni zbytecne brzden (pokud je mate za sebou, tak se treba
>> bude hodit jinym):
>>
>>    * Pouzijte rozumne mladou verzi db serveru, 8.3+. Prinasi mj.
>>      znacne optimalizacni moznosti.
>>
>>    * Dejte postgresu dost pracovni pameti. Toto neni jednoducha
>>      zalezitost, odkazuju na specializovane weby a skvely manual.
>>
>>    * Pouzijte volbu log_min_duration_statement = N pro logovani
>>      prikazu trvajicich vice nez N milisekund. V shellu lze pak
>>      provest prikaz EXPLAIN ANALYZE <prikaz> (pokud jde o zapisovy
>>      prikaz, spustte ho v shellu ve vlastni transakci). Vysledkem
>>      bude takzvany query plan. Pokud si nevite rady s jeho
>>      uzitecnosti a nenastudujete ji, navstivte IRC kanal 
>> #postgresql
>>      na siti FreeNode. Nachazi se tam zdaleka nejnapomocnejsi
>> komunita, na kterou jsem kdy na Netu narazil.
>>
>>      Pomohli mi vytvorit konkretni INDEX pro konkretni SELECT, 
>> ktery
>>      bych mel fakt problem vypotit a ktery 700ms prikaz zrychlil na
>>      3ms. V jinem pripade mi bylo doporuceno prepsat prikaz v
>>      aplikacni vrstve, protoze kvuli zisku 20 radku jich prochazel
>>      desetitisice a slo to udelat jinak.
>>
>>      Indexy na jednu stranu zabiraji misto na disku a zpomaluji
>>      zapisy (to vam muze vadit), umi zazracne zrychlit SELECTy.
>>      Mrknete, jestli vam zapis nezpomaluje nejaky
>>      stary/neoptimalni/na-az-tak-potrebny index.
>>
>>
>>
>>    * V dobe mensiho provozu provedte globalni VACUUM FULL ANALYZE
>>      (treba s odstavkou db) -- pozor, zamyka tabulky. Tim se
>>      aktualizuji optimalizacni statistiky, odstrani se nepouzivane
>>      radky a databaze se na disku setrese treba na polovinu i mene.
>>      Jsou clanky na Netu tvrdici, ze jeste lepsi optimalizacni
>>      vysledky ma vytvoreni nove databaze z dumpu. Neni duvod tomu
>>      neverit, pokud mate tu moznost, vedle to otestujte.
>>
>>    * S tydenni periodou v dobe mensiho provozu provadejte VACUUM
>>      ANALYZE. Na vse nebo jen na exponovane tabulky.
>>
>>    * Muze pomoci i prikaz REINDEX pro znovuvytvoreni potencialne
>>      neoptimalnich indexu. To je na celou db relativne rychle.
>>
>>
>> Nejsem odbornikem na databaze a postgres, treba me nekdo
>> opravi/doplni.
>> I na ceskem Netu jsou clanky, ktere prinaseji potrebny vhled.
>> Anglicky
>> je jich mnohem vic vcetne presnych receptu.
>>
>> --
>> \//\/\ : Vladimir Macek : http://macek.sandbox.cz : +420 608 978 
>> 164
>>
>>
>
>
>
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux