Re: More shared buffers causes lower performances
От | Pavel Stehule |
---|---|
Тема | Re: More shared buffers causes lower performances |
Дата | |
Msg-id | 162867790712260912p1e00dd75yfaebf6fffe6d2403@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: More shared buffers causes lower performances ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Список | 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.smet@gmail.com> wrote: > On Dec 26, 2007 12:21 PM, Simon Riggs <simon@2ndquadrant.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 >
В списке pgsql-performance по дате отправления: