From: | Cosimo Streppone <cosimo(at)streppone(dot)it> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Postgresql Performance list <pgsql-performance(at)postgresql(dot)org>, Jim Nasby <jim(at)nasby(dot)net>, Richard Huxton <dev(at)archonet(dot)com> |
Subject: | Re: Context switch storm |
Date: | 2006-11-14 21:43:20 |
Message-ID: | 455A3878.20702@streppone.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Merlin wrote:
> On 11/14/06, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
>
>> On Tue, Nov 14, 2006 at 09:17:08AM -0500, Merlin Moncure wrote:
>> > On 11/14/06, Cosimo Streppone <cosimo(at)streppone(dot)it> wrote:
>> > >I must say I lowered "shared_buffers" to 8192, as it was before.
>> > >I tried raising it to 16384, but I can't seem to find a relationship
>> > >between shared_buffers and performance level for this server.
>> >
>> > My findings are pretty much the same here.
>> > [...]
>>
>> BTW, shared_buffers of 16384 is pretty low by today's standards
>
> Can you think of a good way to construct a test case that would
> demonstrate the difference?
Not sure of actual relevance, but some time ago I performed
(with 8.0) several pg_bench tests with 1,5,10,20 concurrent
clients with same pg configuration except one parameter for
every run.
In one of these tests I run pgbench with shared_buffers starting
at 1024 and doubling it to 2048, ..., until 16384.
I found the best performance in terms of transactions per second
around 4096/8192.
That said, I don't know if pgbench stresses the database
like my typical oltp application does.
And also, I suspect that shared_buffers should not be
evaluated as an absolute number, but rather as a number relative to
maximum main memory (say 1/2 the total ram, 1/3, 2/3, ...).
--
Cosimo
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-11-15 09:07:16 | Re: Context switch storm |
Previous Message | Merlin Moncure | 2006-11-14 20:11:40 | Re: Context switch storm |