Re: postgres 9.3 vs. 9.4

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: "Mkrtchyan, Tigran" <tigran(dot)mkrtchyan(at)desy(dot)de>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: postgres 9.3 vs. 9.4
Date: 2014-09-18 22:16:13
Message-ID: 541B59AD.9020109@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 19/09/14 09:10, Mkrtchyan, Tigran wrote:
>
>
> ----- Original Message -----
>> From: "Mark Kirkwood" <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
>> To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "Tigran Mkrtchyan" <tigran(dot)mkrtchyan(at)desy(dot)de>
>> Cc: "postgres performance list" <pgsql-performance(at)postgresql(dot)org>
>> Sent: Thursday, September 18, 2014 10:56:36 PM
>> Subject: Re: [PERFORM] postgres 9.3 vs. 9.4
>>
>> On 19/09/14 08:32, Merlin Moncure wrote:
>>> On Thu, Sep 18, 2014 at 4:58 AM, Mkrtchyan, Tigran
>>> <tigran(dot)mkrtchyan(at)desy(dot)de> wrote:
>>>>
>>>> 9.3.5:
>>>> 0.035940 END;
>>>>
>>>>
>>>> 9.4beta2:
>>>> 0.957854 END;
>>>
>>>
>>> time being spent on 'END' is definitely suggesting i/o related issues.
>>> This is making me very skeptical that postgres is the source of the
>>> problem. I also thing synchronous_commit is not set properly on the
>>> new instance (or possibly there is a bug or some such). Can you
>>> verify via:
>>>
>>> select * from pg_settings where name = 'synchronous_commit';
>>>
>>> on both servers?
>>>
>>
>> Yes, does look suspicious. It *could* be that the 9.4 case is getting
>> unlucky and checkpointing just before the end of the 60s run, and 9.3
>> isn't.
>
> 10 minutes run had the same results.
>
> Is there some kind of statistics which can tell there time is spend?
> Or the only way is to run on solaris with dtrace? For me it's more important
> to find why I get only 1500tps with 9.3. The test with 9.4 was just a hope for
> a magic code change that will give me a better performance.
>
>

Interesting. With respect to dtrace, you can use systemtap on Linux to
achieve similar things.

However before getting too carried away with that - we already *know*
that 9.4 is spending longer in END (i.e commit) than 9.3 is. I'd
recommend you see what wal_sync_method is set to on both systems. If it
is the same, then my suspicion is that one of the SSD's needs to be
trimmed [1]. You can do this by running:

$ fstrim /mountpoint

Also - are you using the same filesystem and mount options on each SSD?

Cheers

Mark

[1] if fact, for the paranoid - I usually secure erase any SSD before
performance testing, and then check the SMART counters too...

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2014-09-18 22:49:05 Re: postgres 9.3 vs. 9.4
Previous Message Jeff Janes 2014-09-18 21:34:26 Re: postgres 9.3 vs. 9.4