| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
|---|---|
| To: | domenico febbo <mimmopasticcio(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Jeison Bedoya Delgado <jeisonb(at)audifarma(dot)com(dot)co>, "pgsql-performance(at)postgresql(dot)org list" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: hyperthreadin low performance |
| Date: | 2015-07-25 04:10:30 |
| Message-ID: | 55B30C36.1090607@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 23/07/15 23:37, domenico febbo wrote:
> is the problem also in PostgreSQL 9.4.x?
> I'm going to buy a production's server with 4 sockets E7-4850 12 cores
> so 12*4 = 48 cores (and 96 threads using HT).
>
> What do you suggest?
> Using or not HT?
>
From my experience 9.4 is considerably better (we are using it on the
60 core box mentioned prev).
48 cores should be fine, enabling HT and asking Postgres to effectively
handle 96 could provoke issues. However it is reasonably easy to test -
tune shared_buffers and checkpoint segments sensibly and run pgbench for
a steadily increasing number of clients. With 48 cores you should
(hopefully) see a tps curve that increases and then gently flattens off
somewhere. If 96 cores are "too many" then you will see a tps curve that
initially increases then sharply drops.
Cheers
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig James | 2015-07-25 14:50:35 | Are many idle connections bad? |
| Previous Message | Jeff Janes | 2015-07-24 22:27:28 | Re: bitmap heap scan recheck for gin/fts with no lossy blocks |