From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>, "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc> |
Subject: | Re: More shared buffers causes lower performances |
Date: | 2007-12-26 17:12:21 |
Message-ID: | 162867790712260912p1e00dd75yfaebf6fffe6d2403@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hello
I tested it and it is true. In my configuration 1GRam, Fedora 8, is
PostgreSQL most fast with 32M shared buffers :(. Diff is about 5% to
256M
Regards
Pavel Stehule
On 26/12/2007, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> wrote:
> On Dec 26, 2007 12:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > bgwriter_lru_maxpages = 0
> >
> > So we can see if the bgwriter has any hand in this?
>
> It doesn't change the behaviour I have.
>
> It's not checkpointing either as using pgbench-tools, I can see that
> tps and latency are quite stable during the entire run. Btw, thanks
> Greg for these nice tools.
>
> I thought it may be some sort of lock contention so I made a few tests
> with -N but I have the same behaviour.
>
> Then I decided to perform read-only tests using -S option (pgbench -S
> -s 100 -c 16 -t 30000 -U postgres bench). And still the same
> behaviour:
> shared_buffers=64MB : 20k tps
> shared_buffers=1024MB : 8k tps
>
> Any other idea?
>
> --
> Guillaume
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2007-12-26 17:20:15 | Re: More shared buffers causes lower performances |
Previous Message | Mark Mielke | 2007-12-26 16:23:28 | Re: With 4 disks should I go for RAID 5 or RAID 10 |