On 26/08/14 10:13, Josh Berkus wrote:
On 08/22/2014 07:02 AM, Andres Freund wrote:
On 2014-08-21 14:02:26 -0700, Josh Berkus wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
Not sure how you can make such a blanket statement when so many people
have tested and shown the benefits of hyper-th
On 26/08/14 10:13, Josh Berkus wrote:
On 08/22/2014 07:02 AM, Andres Freund wrote:
On 2014-08-21 14:02:26 -0700, Josh Berkus wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
Not sure how you can make such a blanket statement when so many people
have tested and shown the benefits of hyper-th
On 08/22/2014 07:02 AM, Andres Freund wrote:
> On 2014-08-21 14:02:26 -0700, Josh Berkus wrote:
>> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
>>> Not sure how you can make such a blanket statement when so many people
>>> have tested and shown the benefits of hyper-threading.
>>
>> Actually, I d
On 2014-08-21 14:02:26 -0700, Josh Berkus wrote:
> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
> > Not sure how you can make such a blanket statement when so many people
> > have tested and shown the benefits of hyper-threading.
>
> Actually, I don't know that anyone has posted the benefits of
On 08/22/2014 01:37 AM, Scott Marlowe wrote:
I thought they were fixed in 3.8.something? We're running 3.8 on our
production servers but IO is not an issue for us.
Yeah. 3.8 fixed a ton of issues that were plaguing us. There were still
a couple patches I wanted that didn't get in until 3.11+,
On Thu, Aug 21, 2014 at 5:29 PM, Josh Berkus wrote:
> On 08/21/2014 04:08 PM, Steve Crawford wrote:
>> On 08/21/2014 03:51 PM, Josh Berkus wrote:
>>> On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256
On 08/21/2014 04:29 PM, Josh Berkus wrote:
On 08/21/2014 04:08 PM, Steve Crawford wrote:
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currentl
On 22/08/14 11:29, Josh Berkus wrote:
On 08/21/2014 04:08 PM, Steve Crawford wrote:
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set t
On 08/21/2014 04:08 PM, Steve Crawford wrote:
> On 08/21/2014 03:51 PM, Josh Berkus wrote:
>> On 08/21/2014 02:26 PM, Scott Marlowe wrote:
>>> I'm running almost the exact same setup in production as a spare. It
>>> has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
>>> it's a spa
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
it's a spare node I might be able to do some testing on it as well.
It
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
> I'm running almost the exact same setup in production as a spare. It
> has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
> it's a spare node I might be able to do some testing on it as well.
> It's running a 3.2 kernel right now. I c
> HT off is common knowledge for better benchmarking result
It's wise to use the qualifer 'for better benchmarking results'.
It's worth keeping in mind here that a benchmark is not the same as normal
production use.
For example, where I work we do lots of long-running queries in parallel over
On Thu, Aug 21, 2014 at 3:26 PM, Scott Marlowe wrote:
> On Thu, Aug 21, 2014 at 3:02 PM, Josh Berkus wrote:
>> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
>>
>>> I am also
>>> unclear exactly what you tested, as I didn't see it mentioned in the
>>> email --- CPU type, CPU count, and operating sy
On Thu, Aug 21, 2014 at 3:02 PM, Josh Berkus wrote:
> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
>
>> I am also
>> unclear exactly what you tested, as I didn't see it mentioned in the
>> email --- CPU type, CPU count, and operating system would be the minimal
>> information required.
>
> Ooops!
On Thu, Aug 21, 2014 at 02:17:13PM -0700, Josh Berkus wrote:
> >> Actually, I don't know that anyone has posted the benefits of HT. Link?
> >> I want to compare results so that we can figure out what's different
> >> between my case and theirs. Also, it makes a big difference if there is
> >> an
On 08/21/2014 02:11 PM, Bruce Momjian wrote:
> On Thu, Aug 21, 2014 at 02:02:26PM -0700, Josh Berkus wrote:
>> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
>>> On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
On a read-write test, it's 10% faster with HT off as well.
Furt
On Thu, Aug 21, 2014 at 02:02:26PM -0700, Josh Berkus wrote:
> On 08/20/2014 07:40 PM, Bruce Momjian wrote:
> > On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
> >> On a read-write test, it's 10% faster with HT off as well.
> >>
> >> Further, from their production machine we've seen th
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
> On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
>> On a read-write test, it's 10% faster with HT off as well.
>>
>> Further, from their production machine we've seen that having HT on
>> causes the machine to slow down by 5X whenever you g
On 08/20/2014 06:14 PM, Mark Kirkwood wrote:
Notwithstanding the above results, my workmate Matt made an interesting
observation: the scaling graph for (our) 60 core box (HT off), looks
just like the one for our 32 core box with HT *on*.
Hmm. I know this sounds stupid and unlikely, but has any
On 21/08/14 11:14, Mark Kirkwood wrote:
You didn't mention what
cpu this is for (or how many sockets etc), would be useful to know.
Just to clarify - while you mentioned that the production system was 40
cores, it wasn't immediately obvious that the same system was the source
of the measure
> On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
>> On a read-write test, it's 10% faster with HT off as well.
>>
>> Further, from their production machine we've seen that having HT on
>> causes the machine to slow down by 5X whenever you get more than 40
>> cores (as in 100% of real
On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
> On a read-write test, it's 10% faster with HT off as well.
>
> Further, from their production machine we've seen that having HT on
> causes the machine to slow down by 5X whenever you get more than 40
> cores (as in 100% of real cores
On Wed, Aug 20, 2014 at 1:36 PM, Shaun Thomas wrote:
> That's so strange. Back when I did my Nehalem tests, we got a very strong
> 30%+ increase by enabling HT. We only got a hit when we turned off turbo, or
> forgot to disable power saving features.
In my experience, it is crucially important to
On 21/08/14 07:13, Josh Berkus wrote:
Mark, all:
So, this is pretty damming:
Read-only test with HT ON:
[pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench
starting vacuum...end.
transaction type: SELECT only
scaling factor: 30
query mode: simple
number of clients: 20
number of threads: 4
durati
On 08/20/2014 02:13 PM, Josh Berkus wrote:
So we're definitely back to "If you're using PostgreSQL, turn off
Hyperthreading".
That's so strange. Back when I did my Nehalem tests, we got a very
strong 30%+ increase by enabling HT. We only got a hit when we turned
off turbo, or forgot to disab
Mark, all:
So, this is pretty damming:
Read-only test with HT ON:
[pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench
starting vacuum...end.
transaction type: SELECT only
scaling factor: 30
query mode: simple
number of clients: 20
number of threads: 4
duration: 600 s
number of transactions actuall
26 matches
Mail list logo
