| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | grb(at)skogoglandskap(dot)no, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4) |
| Date: | 2015-07-08 13:56:51 |
| Message-ID: | 20953.1436363811@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> So there's an interesting "dip" between 4 and 8 clients. A perf profile
> doesn't show any actual lock contention on master. Not that surprising,
> there shouldn't be any exclusive locks here.
What size of machine are you testing on?
I ran Graeme's tests on a 2-socket, 4-core-per-socket, no-hyperthreading
machine, which has separate NUMA zones for the 2 sockets. What I saw
(after fixing the "stable" issue) was that all the 8-client and 16-client
cases were about 8x faster than 1-client, and 2-client was generally
within hailing distance of 2x faster, but 4-client was often noticeably
worse than the expected 4x faster.
I figured this was likely some weird NUMA effect, possibly compounded
by brutally stupid scheduling on the part of my kernel. But I didn't
have time to look closer.
You might be seeing the same kind of effect, or something different.
It's hard to tell without knowing more about your machine.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-07-08 14:22:41 | Re: BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4) |
| Previous Message | Andres Freund | 2015-07-08 13:27:49 | Re: BUG #13494: Postgresql database displays first column data on merging of two columns in the Select statement |