Re: Linux: more cores = less concurrency.

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <david(at)lang(dot)hm>,"Steve Clark" <sclark(at)netwolves(dot)com>, "Glyn Astill" <glynastill(at)yahoo(dot)co(dot)uk>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Linux: more cores = less concurrency.
Date: 2011-04-12 14:43:01
Message-ID: 4DA41EA5020000250003C6E1@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Glyn Astill <glynastill(at)yahoo(dot)co(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Glyn Astill 2011-04-12 16:01:49 Re: Linux: more cores = less concurrency.
Previous Message Tom Lane 2011-04-12 14:38:27 Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?