Kevin Grittner wrote:
Claire Chang wrote:
shared_buffers = 32GB
I seem to remember seeing some benchmarks showing that performance
falls off after 10GB or 20GB on that setting.
Not even quite that high. I've never heard of a setting over 10GB being
anything other than worse th
On 08/05/2011 09:58 AM, Kevin Grittner wrote:
What I'm saying is that if processes are blocked waiting for disk
they are not going to be using CPU, and there is room for that many
additional processes to be useful, as the CPUs and other drives
would otherwise be sitting idle.
Haha. The way you
"Kevin Grittner" wrote:
> which would typically be running with 26 blocked waiting
> on a read for a cache miss,
I meant 24 there.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
Shaun Thomas wrote:
> On 08/05/2011 09:00 AM, Kevin Grittner wrote:
>
>> optimal pool size = ((2 * actual core count) + effective spindle
>> count)
>
> How does that work? If your database fits in memory, your optimal
> TPS is only constrained by CPU. Any fetches from disk reduce your
> throughp
On 08/05/2011 09:00 AM, Kevin Grittner wrote:
optimal pool size = ((2 * actual core count) + effective spindle
count)
How does that work? If your database fits in memory, your optimal TPS is
only constrained by CPU. Any fetches from disk reduce your throughput
from IO Waits. How do you accou
Shaun Thomas wrote:
> So with a dual X5675, that's 12 cores. My numbers peaked at
> 24-concurrency. At that concurrency, HT was 60% faster than
> non-HT. Sorry if I mixed my terminology. :)
No problem -- I appreciate the information. I just wanted to be
sure I was understanding it correctly
On 08/04/2011 04:54 PM, Kevin Grittner wrote:
it peaked at 2x physical cores, where it ended up being 60%
faster than true cores.
Not sure I understand the terminology here -- "physical cores" is
counting HT or not?
No. So with a dual X5675, that's 12 cores. My numbers peaked at
24-concurre
Shaun Thomas wrote:
> it peaked at 2x physical cores, where it ended up being 60%
> faster than true cores.
Not sure I understand the terminology here -- "physical cores" is
counting HT or not?
Thanks,
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
On 08/04/2011 04:36 PM, Kevin Grittner wrote:
Anyway, I'm always willing to take advantage of the benchmarking
work of others, so I'm very curious about where performance topped
out for you with HT enabled, and whether disk waits were part of the
mix.
Hah. Well, it peaked at 2x physical cores,
Shaun Thomas wrote:
> On 08/04/2011 03:38 PM, Kevin Grittner wrote:
>
>> You're probably going to get better performance by setting that
>> to 2 to 3 times the number of actual cores (don't county
>> hyperthreading for this purpose), and using a connection pooler
>> to funnel the 600 user connect
On Thu, Aug 4, 2011 at 2:38 PM, Kevin Grittner
wrote:
> Claire Chang wrote:
>
>> hi, We recently bought a 4 8core 128G memory database server and I
>> am setting it up to replace our old 4 4cores 128G memory database
>> server as a master. The memory related settings that we use on
>> the old ma
On 08/04/2011 03:38 PM, Kevin Grittner wrote:
You're probably going to get better performance by setting that to 2
to 3 times the number of actual cores (don't county hyperthreading
for this purpose), and using a connection pooler to funnel the 600
user connections down to a smaller number of da
Claire Chang wrote:
> hi, We recently bought a 4 8core 128G memory database server and I
> am setting it up to replace our old 4 4cores 128G memory database
> server as a master. The memory related settings that we use on
> the old machine seem a bit wrong according to the experts on IRC:
> m
13 matches
Mail list logo
