Dotaz: Vhodný podvozek pro PostgreSQL - důležitá je pouze rychlost

[Petr]

Ahoj,
rád bych se zeptal, na jaký systém a filesystem je nejlepší nasadit PostgreSQL.

Hlavním kritériem je rychlost (spolehlivost je až na druhém místě, navíc jde v 99% o čtení dat).

HW: prozatím bohužel obyčejné PC, RAM - 2GB;
velikost DB - 4,5 GB

Jaký systém by byl nejvhodnější (z hlediska rychlosti)? Linux, BSD, OpenSolaris? - v jaké verzi jádra, s jakým plánovačem apod?

v kombinaci s jakým filesystémem? EXT4, ZFS, ... - s jakým nastavením? (např. vypnutí bariér není problém)

S jakým nastavením PostgreSQL?

Případně co dalšího ještě nastavit, aby to bylo prostě nejrychlejší?

Předem díky za vaše tipy a zkušenosti.

Petr

---

---

Odpovědi

[okbob]

Tak pokud se bude převážně číst - tak vliv filesystému, os. je mizivý - pokud pg najde data v cache - základem je mít co nejvíc RAM - tedy 64 bit O.S. a pokud možno co nejvíc paměti. Zbytek hraje relativně malou roli. Pokud dokoupíte ještě 2G RAM, tak aby byla celá db v paměti, tak se nemusíte starat o nic jiného.

[Petr]

To máte pravdu. Přidám paměť a zkusím nějak poštělovat nastavení Postgresu, aby tu paměť používal. Díky

[cronin]

Přidám paměť a zkusím nějak poštělovat nastavení Postgresu, aby tu paměť používal.

To uz samozrejme urobili za Teba ini, a boli to ludia, ktori do vnutornosti PostreSQL videli dost dobre.

[okbob]

Pokud tam poběží relativně jednoduché dotazy, tak stačí nastavit shared_buffers a effective_cache_size.

[cronin]

To je IMHO prilis zjednodusene. Tie parametre su sice skutocne dolezite, ale su v silnej interakcii s inymi parametrami, napr. s podcenovanym parametrom max_connections.

[okbob]

Ne - ono je to jednoduche. S parametrem max_connection souvisi parametr work_mem, ktery jsem zde neuvedl - s tim, ze predpokladam, ze se jedna o jednoduche dotazy a staci default - 100 (max_connection-default) * 1MB = 100MB coz je v 4GB stroji pomerne zanedbatelne.

jinak musi platit

max_connection * work_mem + shared+buffers < 2/3 RAM

Nic slozitejsiho tam neni. PostgreSQL lze relativne dobre nakonfigurovat pomerne snadno - zaklad - server nesmi swapovat.

ty 2/3 jsou orientační pro dedikovaný server. Vždy je potřeba server nějaký čas sledovat a pokusit se o optimalizaci.

[cronin]

Suhlasim. Ale prave kvoli tomu, aby sa zabranilo swapovaniu a zaroven sa vyuzivalo vsetka dostupna pamat, treba globalne zdroje a zdroje "per session" posudzovat spolu. Odkial je ten 1MB? Hadam, ze je to defaultne nastavenie work_mem? Pokial si pamatam nase projekty, kde sme ladili PostgreSQL/EnterpriseDB, pamat "per session" bola vyrazne vyssia ako 1MB. Ono je dost rozdiel, ci sa napr. taky ORDER BY alebo JOIN urobi v pamati, alebo sa udaje musia presypat cez docastnu tabulku.

Prave EnterpriseDB to ma pekne vyriesene: staci urobit 3 veci:

1) Nastavit dostatocnu velkost shared memory v OS; niektore systemy maju defaultne nastavenie prilis nizke, alebo shared memory vobec nemusia mat. Nasledne zakomentovat shared_buffers v konfiguraku PostgreSQL; by default odkomentovana hodnota ja prilis nizka, aby databaza nastartovala aj na tych OS, ktore maju default limity pre zdielanu pamat nizke.

2) Specifikovat maximalny pocet spojeni; zlate pravidlo je "as many as necessary, as few as possible". Tym sa zabezpeci maximalizacia zdrojov pouzitelnych "per session". A ak sa bavime o nejakom kontajnerovom prostredi, kde sa pristup k databaze riesi cez connection pool-y, je zistenie potrebneho poctu spojeni trivialne.

3) Specifikovat, kolko percent fyzickej pamate sa moze pouzit pre instanciu. Podla toho sa "dopocitaju" globalne zdroje. Opat sa jedna o relativne trivialnu zalezitost, najma pokial ide o dedikovany databazovy stroj.

Podla mojich skusenosti je vysledna konfiguracia v EnterpriseDB velmi dobra, a to prakticky bez roboty.

Uz len dodam pre povodneho opytujuceho sa, ze to, co robi databazovu aplikaciu rychlou alebo pomalou, je zvycajne dobry resp. zly navrh udajovych struktur, nie ladenie cisel v konfiguraku. Ziadne fast=true nastavenie neexistuje.

[okbob]

Nástřel work_mem je dost obtížnější - a nedá se řešit "od stolu". Je potřeba se podívat na konkrétní pomalé dotazy a zjistit si kolik potřebují. Pro mne je wizard v EnterpriseDB spíš na škodu - neřeší nic víc než výše uvedenou rovnici s několika variantami výchozích proměmnných - tváří se sofistikovaně - takže se DBA nenaučí správně nastavovat paměť a ani se o to nepokoušejí. Na druhou stranu, je to pořád lepší, než když někdo používá pg s výchozím nastavením.

Navíc se aktivuje pouze při instalaci. Méně znalí DBA při problémech a nedostatku connection pak jednoduše izolovaně zvednou max_connection bez ohledu na další parametry, čímž to totálně zazdí.

S ostatním souhlas.

[cronin]

Navíc se aktivuje pouze při instalaci.

Tak tomuto nerozumiem. Ziadny installation-time wizard som nikdy pre EnterpriseDB nepouzil. To je nejaka novinka? Pokial viem, EnterpriseDB "odvodi" vsetky parametre, ktore nie su specifikovane v konfiguraku, pri svojom starte. Tym sa vyrovna napr. so zmenou velkosti fyzickej RAM. Jednoducho zatial co v pripade startu PostgreSQL plati "ak je to v konfiguraku zakomentovane, pouzi hardkodovanu hodnotu", tak v pripade startu EnterpriseDB plati "ak je to v konfiguraku zakomentovane, vypocitaj vhodnu hodnotu vzhladom na environment".

[okbob]

Je to možné - s EDB jsem si dva roky nehrál. Na druhou stranu mi to přijde dost riskantní.

měl jsem na mysli EDB TuningWizard.

[Petr]

Pánové, díky moc za tipy - byly pro mě poučné - např. EDB TunningWizard jsem vůbec neznal.

[cronin]

Aha. No, ja netusim co je EDB TuningWizard. Vsetko, co som pisal, plati pre normalnu databazovu instanciu a normalnu konfiguraciu databazoveho servera.

[Vskutečnosti Saýc]

A tomu, pratele, se rika neortogonalni navrh.

[cronin]

Svet, zial, nie je cierno-biely. V realnom svete su limitovane zdroje, v tomto pripade pamat. Ta sa musi rozdelit medzi globalne zdroje a medzi "per-session" zdroje. Ak si niekto necha nastavenych defaultnych 100 pripojeni napriek tomu, ze mu bohate staci 10, bude vyuzivat iba desatinu "per-session" pamate a 10x pravdepodobnejsie jeho ORDER BY povedie k vytvoreniu docastnej tabulky, namiesto triedenia v pamati. Ak sa to "poriesi" zvysenim work_mem, obmedzia sa tym globalne zdroje, napriklad velkost cache pamate. V horsom pripade bude suma narokov prekracovat dostupnu pamat, operacny system zacne swapovat.

Technicky vzate, tie nastavenia nie su neortogonalne. Kazde meni jednu presne definovanu vlastnost presne definovanym sposobom. Ze nejake nastavenie moze vyemergovat k tazko predikovatelnemu a manazovatelnemu stavu, je skor "chyba" operaneho systemu, ktory sa zavazuje poskytovat aplikacii viac operacnej pamate, ako ma v skutocnosti k dispozicii. Vlastne nevidim dovod, preco by na spravne nakonfigurovanom dedikovanom databazovom serveri mal byt akykolvek swap pritomny.

[okbob]

Ono to asi ani jinak jednoduse nejde - ani O.S. ani db nema kristalovou kouli, by bylo jasne jake SQL prikazy prijdou v nasledujicich okamzicich, a jaky bude jejich soubeh. Stavajici design je zalozen na silnem zjednoduseni - napr. se predpoklada, ze pristup ke vsem blokum souboru bude stejne rychly, random I/O je 4x pomalejsi nez sekvencni cteni, neresi se, zda-li blok v cache, ... A kupodivu to funguje - s nicim lepsim zatim nikdo neprisel.

[cronin]

A kupodivu to funguje - s nicim lepsim zatim nikdo neprisel.

Ale no tak, samozrejme, ze prisiel. To sa uz ale dostavame do kategorie tazkotonaznych rieseni ako napr. Oracle.

[okbob]

Oracle je extrémně těžkotonážní :)

[Hlípa]

Par doplneni:

1) Je treba mit i prekompilovany 64bitovy PostgreSQL pokud chcete pouzivat vice jak 3.2GB RAM (ne vsechny procesory umi adresovat 4GB), a je treba pocitat s tim, ze je nutne provest novou inicializaci databaze. 32bitovy a 64bitovy PG ma jinou On Disk Structure.

2) 64bitova aplikace muze a nemusi byt rychlejsi. Volani funkci je rychlejsi, ale operace s pameti jsou pomalejsi, neb TLB ma vice urovni, ktere je nutne prochazet k dohledani fyzicke adresy.

3) Vic buffer cache muze znamenat i zpomaleni. Z vlastni zkusenosti vim, ze zvednutim shared_buffers z 1GB na 2GB se databaze vyrazne zpomalila (neb se bohate vesla do tho 1GB). Projevil se efekt prochazeni delsich seznamu. Napriklad checkpoint trva dele apod.

Zaver je, ze je nutne si to otestovat.

[Petr]

S bodem 1 a 2 jsem počítal, nicméně u bodu 3 bych si asi taky neuvědomil, že se DB může výrazně zpomalit, takže díky za tip.

[Tomáš]

Jenom doplním, že výkon bude záležet hodně na disku. Pokud potřebuje opravdu rychlost, tak bych koukal po SAS discích s 15000 rpm. Na SAS budete potřebovat asi nový řadič. Možná bych taky uvažoval o RAID 0.

[Tomáš]

Jo koukám, že jsem přehlédl, že Vaše DB má jen 4,5 GB. Takže beru zpět. Asi postačí pokud budete mít dostatek paměti, jak již psal P.Stěhule. Při téhle velikosti by se dala DB i nacpat na SSD disk.

[Vskutečnosti Saýc]

Ja bych navrhly rychlost databaze ignorovat, nijak netunit souborovy system, ale upravit aplikaci aby umela pouzivat memcached. I hodne hloupe cachovani (klic = md5, hodnota = vysledek db dotazu, data se po triceti sekundach musi nacist znovu) dotaze udelat z pomale databaze neco neuveritelneho.

[Vskutečnosti Saýc]

"navrhl". Neumim psat.

[okbob]

s tím musím souhlasit - ještě před použitím db popřemýšlejte o memcached.

[mecheche]

nebo jeste lepe MemcacheDB

[Petr]

Díky, s Memcached zkušenosti nemám, podívám se na to, ale pokud budu mít dostatek paměti, tak si říkám, že by cache Hibernatu mohla udělat stejnou službu.