Glyn Astill <glynast...@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
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
