| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <david(at)lang(dot)hm>,"Steve Clark" <sclark(at)netwolves(dot)com>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "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-11 21:35:47 |
| Message-ID: | 4DA32DE3020000250003C68E@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> I don't know why you were hitting the knee sooner than I've seen
> in my benchmarks
If you're compiling your own executable, you might try boosting
LOG2_NUM_LOCK_PARTITIONS (defined in lwlocks.h) to 5 or 6. The
current value of 4 means that there are 16 partitions to spread
contention for the lightweight locks which protect the heavyweight
locking, and this corresponds to your best throughput point. It
might be instructive to see what happens when you tweak the number
of partitions.
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.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rees | 2011-04-11 22:11:29 | Re: Linux: more cores = less concurrency. |
| Previous Message | Glyn Astill | 2011-04-11 21:08:09 | Re: Linux: more cores = less concurrency. |