Обсуждение: hyperthreadin low performance

hi everyone,

Recently update a database to machine with RHEL7, but i see that the
performance is betther if the hyperthreading tecnology is deactivated
and use only 32 cores.

is normal that the machine performance is better with 32 cores that 64
cores?.

BD: postgresql 9.3.5
Machine: Dell PE R820
processor:  4x Intel(R) Xeon(R) CPU E5-4620 v2 @ 2.60GHz eigth-core
RAM: 128GB
Storage SSD SAN

thanks by your help

--
Atentamente,


JEISON BEDOYA DELGADO
ADM.Servidores y comunicaciones
AUDIFARMA S.A.

On 21/07/15 20:04, David Rowley wrote:
> On 21 July 2015 at 14:59, Jeison Bedoya Delgado
> <jeisonb@audifarma.com.co <mailto:jeisonb@audifarma.com.co>> wrote:
>
>     hi everyone,
>
>     Recently update a database to machine with RHEL7, but i see that the
>     performance is betther if the hyperthreading tecnology is
>     deactivated and use only 32 cores.
>
>     is normal that the machine performance is better with 32 cores that
>     64 cores?.
>
>
> You might be interested in
> http://www.postgresql.org/message-id/53F4F36E.6050003@agliodbs.com
>

However I do wonder if we have been misinterpreting these tests. We tend
to assume the position of "see hyperthreading is bad, switch it off".

The linked post under the one above:

http://www.postgresql.org/message-id/53ED371D.109@catalyst.net.nz

shows that 60 core (no hyperthreading) performance is also pessimal,
leading me to conclude that *perhaps* it is simply the number of cores
that is the problem - particularly as benchmark results for single
socket cpus clearly show hyperthreading helps performance...

Regards

Mark

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?

BR
Domenico

2015-07-21 11:07 GMT+02:00 Mark Kirkwood <mark.kirkwood@catalyst.net.nz>:
> On 21/07/15 20:04, David Rowley wrote:
>>
>> On 21 July 2015 at 14:59, Jeison Bedoya Delgado
>> <jeisonb@audifarma.com.co <mailto:jeisonb@audifarma.com.co>> wrote:
>>
>>     hi everyone,
>>
>>     Recently update a database to machine with RHEL7, but i see that the
>>     performance is betther if the hyperthreading tecnology is
>>     deactivated and use only 32 cores.
>>
>>     is normal that the machine performance is better with 32 cores that
>>     64 cores?.
>>
>>
>> You might be interested in
>> http://www.postgresql.org/message-id/53F4F36E.6050003@agliodbs.com
>>
>
> However I do wonder if we have been misinterpreting these tests. We tend to
> assume the position of "see hyperthreading is bad, switch it off".
>
> The linked post under the one above:
>
> http://www.postgresql.org/message-id/53ED371D.109@catalyst.net.nz
>
> shows that 60 core (no hyperthreading) performance is also pessimal, leading
> me to conclude that *perhaps* it is simply the number of cores that is the
> problem - particularly as benchmark results for single socket cpus clearly
> show hyperthreading helps performance...
>
> Regards
>
> Mark
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

On 23 Jul 2015, at 13:37, domenico febbo <mimmopasticcio@gmail.com> 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?
>
> BR


1. If you have enough money to buy a 4-socket E7, then you certainly have enough money to pay someone (maybe yourself)
forthe 30 minutes of work needed to run a benchmark on the machine with and without hyperthreading and compare them.  I
meanliterally, run pgbench, reboot, turn on/off HT, run pgbench. Then you'll know what works best for your
configuration.Don't be lazy about this, it's as important as the money you're throwing at the hardware.  

2. Keep in mind most of the numbers people throw around are pgbench numbers. Pgbench is representative of some
workloads(e.g. bank transactions) and less representative of others (mixed query types, GIS work, scientific work,
heavyIO, interaction with other applications/libraries...). Are you using the server for other tasks besides postgres,
forexample? I find I get better performance with HT when I'm using postgres with GDAL on the same server. Probably
becausethe HT cores are being asked to do two different types of things, which is where HT shines.  

3. IMPORTANT : it doesn't matter how pgbench performs for other people on other computers and what they think is best.
What matters is 'how does YOUR normal workload perform on YOUR computer'.
The best way to do that is to put together a simple simulated workload that looks like your intended use of the system.
Leave it running.
If it's for an important system, look at all aspects of performance: transactions per second, I/O stalls, latency, ...
If you can't do that, pgbench can be used instead.

====

Finally. A serious point. The lack of diversity in postgres benchmarking is quite amazing, to my mind, and is probably
atthe root of the eternal disagreements about optimal settings as well as the existence of long-standing hidden
scaling/performancebugs (or weird kernel interactions). pgbench is useful, but really... let's make some more tools (or
sharelinks, if you know of them).  

Since contribution >>> gripe, here is my own (first, tiny) contribution, which I mentioned earlier in the month:
https://github.com/gbb/ppppt. 

As a point of contrast. Take a look at how computer game players measure the performance of graphics cards and disk
drivesin their product reviews.  
http://www.guru3d.com/articles-pages/radeon-r9-290-review-benchmarks,32.html

32 pages of data and discussion to test the performance of a single model (among thousands of possibilities and
millionsof configurations)! And this article is ordinary, run of the mill stuff in the gaming scene, literally the
firstlink I hit in Google. Has anyone ever in the history of these lists ever posted so much diverse and structured
evidencein support of their beliefs about a postgres setting? 

Gaming reviewers use a multitude of real-world games, synthetic benchmarks, theoretical estimates... as someone with a
footin both worlds it is quite amusing to see that game-players address benchmarking and optimisation of performance
farmore seriously, scientifically (and successfully) than most professional database admins.  

Many graphics card reviews care very much about reproducability/repeated results, surrounding test conditions (very
detailedinformation about other components used in the test, software versioning), warmup effects, benchmark quirks,
performanceat different scales/settings, and so on...  writing 'I saw some post where someone said they got a better
resultfrom XYZ' would certainly not be good enough in that community.   

Graeme Bell.

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