From: | Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | david(at)lang(dot)hm, Steve Clark <sclark(at)netwolves(dot)com>, "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 08:54:59 |
Message-ID: | 768150.83213.qm@web26002.mail.ukl.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
--- On Tue, 12/4/11, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> >> The issue I'm seeing is that 8 real cores
> outperform 16 real
> >> cores, which outperform 32 real cores under high
> concurrency.
> >
> > With every benchmark I've done of PostgreSQL, the
> "knee" in the
> > performance graph comes right around ((2 * cores) +
> > effective_spindle_count). With the database fully
> cached (as I
> > believe you mentioned), effective_spindle_count is
> zero. If you
> > don't use a connection pool to limit active
> transactions to the
> > number from that formula, performance drops off. The
> more CPUs you
> > have, the sharper the drop after the knee.
>
> I was about to say something similar with some canned
> advice to use a
> connection pooler to control this. However, OP
> scaling is more or
> less topping out at cores / 4...yikes!. Here are my
> suspicions in
> rough order:
>
> 1. There is scaling problem in client/network/etc.
> Trivially
> disproved, convert the test to pgbench -f and post results
> 2. The test is in fact i/o bound. Scaling is going to be
> hardware/kernel determined. Can we see
> iostat/vmstat/top snipped
> during test run? Maybe no-op is burning you?
This is during my 80 clients test, this is a point at which the performance is well below that of the same machine limited to 8 cores.
http://www.privatepaste.com/dc131ff26e
> 3. Locking/concurrency issue in heavy_seat_function()
> (source for
> that?) how much writing does it do?
>
No writing afaik - its a select with a few joins and subqueries - I'm pretty sure it's not writing out temp data either, but all clients are after the same data in the test - maybe theres some locks there?
> Can we see some iobound and cpubound pgbench runs on both
> servers?
>
Of course, I'll post when I've gotten to that.
From | Date | Subject | |
---|---|---|---|
Next Message | Glyn Astill | 2011-04-12 08:57:07 | Re: Linux: more cores = less concurrency. |
Previous Message | Sethu Prasad | 2011-04-12 07:51:30 | DBT-5 & Postgres 9.0.3 |