Re: Linux: more cores = less concurrency. - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Linux: more cores = less concurrency.
Date
Msg-id 4DA41EA5020000250003C6E1@gw.wicourts.gov
Whole thread Raw
In response to Re: Linux: more cores = less concurrency.  (Glyn Astill <glynastill@yahoo.co.uk>)
Responses Re: Linux: more cores = less concurrency.
List pgsql-performance
Glyn Astill <glynastill@yahoo.co.uk> wrote:

> Tried tweeking LOG2_NUM_LOCK_PARTITIONS between 5 and 7. My
> results took a dive when I changed to 32 partitions, and improved
> as I increaced to 128, but appeared to be happiest at the default
> of 16.

Good to know.

>> Also, if you can profile PostgreSQL at the sweet spot and again
>> at a pessimal load, comparing the profiles should give good clues
>> about the points of contention.

> [iostat and vmstat output]

Wow, zero idle and zero wait, and single digit for system.  Did you
ever run those RAM speed tests?  (I don't remember seeing results
for that -- or failed to recognize them.)  At this point, my best
guess at this point is that you don't have the bandwidth to RAM to
support the CPU power.  Databases tend to push data around in RAM a
lot.

When I mentioned profiling, I was thinking more of oprofile or
something like it.  If it were me, I'd be going there by now.

-Kevin

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
Next
From: Glyn Astill
Date:
Subject: Re: Linux: more cores = less concurrency.