Re: [PERFORM] hyperthreadin low performance

[Mark Kirkwood]

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


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] hyperthreadin low performance (and some discussion about benchmarking)

[Graeme B. Bell]

On 23 Jul 2015, at 13: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?
> 
> BR


1. If you have enough money to buy a 4-socket E7, then you certainly have 
enough money to pay someone (maybe yourself) for the 30 minutes of work needed 
to run a benchmark on the machine with and without hyperthreading and compare 
them.  I mean literally, 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, heavy 
IO, interaction with other applications/libraries...). Are you using the server 
for other tasks besides postgres, for example? I find I get better performance 
with HT when I'm using postgres with GDAL on the same server. Probably because 
the 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 at the root of the eternal 
disagreements about optimal settings as well as the existence of long-standing 
hidden scaling/performance bugs (or weird kernel interactions). pgbench is 
useful, but really... let's make some more tools (or share links, 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/t. 

As a point of contrast. Take a look at how computer game players measure the 
performance of graphics cards and disk drives in 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 millions of configurations)! And this 
article is ordinary, run of the mill stuff in the gaming scene, literally the 
first link I hit in Google. Has anyone ever in the history of these lists ever 
posted so much diverse and structured evidence in 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 foot in both worlds it is quite 
amusing to see that game-players address benchmarking and optimisation of 
performance far more seriously, scientifically (and successfully) than most 
professional database admins. 

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

Graeme Bell. 

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] hyperthreadin low performance

[domenico febbo]

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 :
> On 21/07/15 20:04, David Rowley wrote:
>>
>> On 21 July 2015 at 14:59, Jeison Bedoya Delgado
>> mailto:jeis...@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.6050...@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@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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] hyperthreadin low performance

[Mark Kirkwood]

On 21/07/15 20:04, David Rowley wrote:

On 21 July 2015 at 14:59, Jeison Bedoya Delgado
mailto:jeis...@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.6050...@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@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

Re: [PERFORM] hyperthreadin low performance

[David Rowley]

On 21 July 2015 at 14:59, Jeison Bedoya Delgado 
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.6050...@agliodbs.com

Regards

David Rowley

--
 David Rowley   http://www.2ndQuadrant.com/

 PostgreSQL Development, 24x7 Support, Training & Services

[PERFORM] hyperthreadin low performance

[Jeison Bedoya Delgado]

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.



--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance