From: Nicolai Petri <none@nicolai--catpipe.net.lh.bsd-dk.dk> To: bsd-dk@bsd-dk.dk Subject: Re: postgresql-tuning på FreeBSD 6.0 release Date: Tue, 22 Aug 2006 23:11:00 +0200
Hej Claus,
Jeg har rodet en del med postgresql performance optimering og kan sige at
trial'n'error er den bedste måde. Hvis du kan lave en testcase der minder
meget om dit produktions load så er det en god reference til at tune din
postgresql installation - alternativt kan du tweake parameterne til pgbench
og bruge timings derfra som reference.
On Tuesday 22 August 2006 22:50, Claus Guttesen wrote:
> Jeg har vredet lidt på min postgresql.conf fil. Dette
> har bevirket en større load på serveren end normalt.
> Jeg har sat shared_buffers ned, og det virkede lidt
> mod sin hensigt lader det til.
Default er shared_buffers=1000 - dette er typisk for lavt på de fleste servere
men du skal bemærke at du sjældent får noget ud af værdier over 10000 på
postgresql 8 og opefter, dog kan det nemt tænkes at specielle typer af load
scenarier vil have gavn af større værdier op til 100000.
>
> Serveren har 8 GB RAM og 2 to-kerne-opteroner.
Mmmm - dejlig server. Og med opteron så sparker postgresql røv :)
>
> På
> http://www.varlena.com/GeneralBits/Tidbits/perf.html
> står der at man skal sætte shared_buffers til en
> værdi, man finder ved at se på shared memory. Et
> værktøj som finder brugen af share memory er ipcs, og
> når jeg skriver ipcs -bm får jeg dette:
>
> sidsel~%>ipcs -bm
> Shared Memory:
> T ID KEY MODE OWNER
> GROUP SEGSZ
> m 131072 5432001 --rw------- pgsql pgsql
> 87719936
>
> Er det segsz jeg skal se på? Er det i såfald i i
> bytes?
Nu virker det som en lidt mærkelig måde at finde værdien på - meget bedre at
finde den optimale værdi for netop dit workload og så tweake dine shared
memory størrelser i kernen derefter. FreeBSD har som default en temmelig lav
grænse for shared memory. Husk også sysctl værdien kern.ipc.shm_use_phys som
angiver om shared memory er virtuel hukommelse eller ej - postgresql er ikke
glad hvis du begynder at swappe i dens shared memory område :)
> Ud fra det bør shared_buffers sættes til minimum 100
> MB, eller 12228.
Lyder fint - men som sagt kommer det helt an på workload. Andre ting jeg som
standard vil foreslå er :
1) effective_cache_size = 1/3 af hukommelsen (på en 100% dedikeret db server)
2) Brug en raid controller med BBU og write-back cache enabled.
3) Put som minimum din transaction log og dine datafiler på 2 forskellige
disksæt.
4) Sænk random_page_cost til mellem 1.4 og 2.5 - dette passer bedre med
postgresqls query optimizer og hastigheden på moderne diske.
5) Øg work_mem - har du få connections til databasen som henter (og sorterer)
større recordset så kan alt mellem 32 og 128 MB give et gevaldigt boost.
6) Sørg for at dine max_fsm_* variabler er store nok. (dead tupples må helst
ikke stige mellem dine periodiske vacuums - husk vacuuming, brug gerne
autovacuum men bemærk at den som default typisk ikke er agressiv nok. Har du
haft problemer med dette så husk at køre en vacuum full for at få ryddet op.
VACUUM FULL VERBOSE er god til at se om man har fået opbygget for mange dead
tupples samt rydde op i det)
7) Øg evt. wal_buffers og checkpoint_segments hvis du har mange
inserts/updates.
8) Sørg for dit database schema er fornuftigt og at de rigtigt indekser
eksisterer.
Det var sådan set lidt mere end jeg havde tænkt mig at skrive - men jeg håber
det hjælper lidt. Skal der mere til vil en beskrivelse af databasens
opbygning hjælpe - men husk at især disk hastighed er vigtig og at f.eks.
RAID-5 er fyfy hvis du vil have god performance.
Med venlig hilsen,
Nicolai Petri
catpipe systems ApS
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:25:03 CET