Lagre int[] i en cell?

[terjeelde]

Hvis du har tildelt PostgreSQL 15GB med RAM, så er det helt meningsløst å la noe av dette være ubrukt hvis det kan brukes til å holde deler av databasen i RAM.

 

Helt enig. For en dedikert database-server, så er det absolutt meningsfult å ha mest mulig av databasen i RAM. OSet gjør en finfin jobb med å passe på at nettopp det skjer.

 

Se for deg følgende:

 

Du har en server med 8GB RAM, 8GB swap, og en database på 6GB.

 

Du gir databaseserveren 7GB med minne, og den cacher en stor del av database.

 

Problemet er at det gjør også OSet. Da ender du opp med å holde data fra databasen dobbelt opp i minne, og trenger egentlig 12GB for bare databasen. Noe må vike, så OS lar enten være å cache hele databasen, og/eller skriver det databasesereren har cachet til swap. Da ender du uansett opp med å måtte lese inn sider fra disk.

 

Alternativt:

 

Du setter opp databaseserveren med nok minne til å gjøre de operasjonene den trenger effektivt (sorts osv), og lar OS cache databasen. Du har 8GB minne, og databasen er på 6GB, så den får lett plass, og du trenger "aldri" å lese fra disk.

 

Databasen må selvsagt vite at ting er på disk for å være ACID-compliant, men det gjør den også. Den kaller fsync() eller tilsvarende, og passer på at OS har skrevet til disk (eller batteri-backed RAM på controller), før den returnerer fra en transaksjon.

 

At data er skrevet til disk gjør jo ikke at OS trenger å slette det fra minne, så ligger fortsatt der klar til bruk.

[kaffenils]

Nå har jeg lest litt flere artikler, og ser nå at du har rett. PostgreSQL overlater mye av cachingen til OSet, pga. problemer som dobbelbuffring.

 

Synes allikevel at det er en merkelig strategi. PostgreSQL stoler på at OSet gjør gode beslutninger på hva som skal ligge i buffer cache og hva som ikke trenger å ligge der, helt ned på 8 kB page-nivå. Snodig....

Endret 8. desember 2008 av kaffenils

[blackbrrd]

Stemmer det nils, som jeg prøvde å si.

 

Argumentasjonen til postgres-utviklerene er bl.a. at det sitter noen å fintuner caching-algoritmene til linux, noe de slipper å bruke tid på.

 

At det fungerer bra er det ikke noen tvil om.

 

Det er greit å tenke på at fram til versjon 7.4 var hovedfokus til postgres prosjektet features, ikke ytelse. Fra versjon 8.0 og oppover har hovedfokuset vært ytelse. Har gått fra 7.4 til 8.1 til 8.3 og alle de skrittene har gitt store ytelsesforbedringer.

[siDDis]

Kan dere ikkje poste nokre av linkene dykk leser denna informasjonen? Eg vil og lære meir om dette

[blackbrrd]

Google søk: http://www.google.no/search?q=postgres+tuning

Første treff: http://www.varlena.com/GeneralBits/Tidbits/perf.html#shbuf

 

På en server med 16gb ram og 60gb data har vi satt shared_buffers til 1gb og effective cache_size til 14gb eller deromkring. Hvis jeg husker riktig.*

 

Det som er viktig er at effective cache size matcher mengden ram OS-et kan bruke til caching.

 

Hvis du setter effective cache size for lavt vil du kunne få sequential scans istedetfor index scans fordi databasen ikke tror nok data vil ligge i minne til at det lønner seg.

 

Hvis du setter effective cache size for høyt vil du kunne få index scans (random access) som går mot harddisken istedetfor ram.

 

Begge disse scenarioene vil øke kosten ved å kjøre en spørring med 10-1000x

 

*top commandoen i linux viser at Linux cacher 14,31gb...

Endret 8. desember 2008 av blackbrrd

[terjeelde]

Kan dere ikkje poste nokre av linkene dykk leser denna informasjonen? Eg vil og lære meir om dette

 

Hiver meg på med litt linker.

 

Hvis du bare skal lese en link, og få rask og grei oversikt, så vil jeg anbefale denne:

http://www.powerpostgresql.com/PerfList/

 

Hvis du vil lese masse-masse, og få med deg mest mulig, så er det oversikt over artikler her:

http://wiki.postgresql.org/wiki/Performance_Optimization