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