| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | david(at)lang(dot)hm, Steve Clark <sclark(at)netwolves(dot)com>, Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>, "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 16:43:55 |
| Message-ID: | BANLkTimaTUHHT9oO24zNgqxVhQUBiPDKWA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Apr 12, 2011 at 6:40 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
> Well, that pretty much clinches it. Your RAM access tops out at 16
> processors. It appears that your processors are spending most of
> their time waiting for and contending for the RAM bus.
It tops, but it doesn't drop.
I'd propose that the perceived drop in TPS is due to cache contention
- ie, more processes fighting for the scarce cache means less
efficient use of the (constant upwards of 16 processes) bandwidth.
So... the solution would be to add more servers, rather than just sockets.
(or a server with more sockets *and* more bandwidth)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | F. BROUARD / SQLpro | 2011-04-12 16:58:47 | Re: Linux: more cores = less concurrency. |
| Previous Message | Kevin Grittner | 2011-04-12 16:40:27 | Re: Linux: more cores = less concurrency. |