Re: Move PinBuffer and UnpinBuffer to atomics

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Date: 2016-04-11 14:04:27
Message-ID: CAPpHfdvP6SerXJx4hUqqLm2_xtQh9Cw0r_Q+MP8OuT2M9+jECQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-04-10 09:03:37 +0300, Alexander Korotkov wrote:
> > On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
> > a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> >
> > > On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> > >
> > >>
> > >>
> > >> On April 9, 2016 12:43:03 PM PDT, Andres Freund <andres(at)anarazel(dot)de>
> > >> wrote:
> > >> >On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
> > >> >> There are results with 5364b357 reverted.
> > >> >
> > >> >Crazy that this has such a negative impact. Amit, can you reproduce
> > >> >that? Alexander, I guess for r/w workload 5364b357 is a benefit on
> that
> > >> >machine as well?
> > >>
> > >> How sure are you about these measurements?
> > >
> > >
> > > I'm pretty sure. I've retried it multiple times by hand before re-run
> the
> > > script.
> > >
> > >
> > >> Because there really shouldn't be clog lookups one a steady state is
> > >> reached...
> > >>
> > >
> > > Hm... I'm also surprised. There shouldn't be clog lookups once hint
> bits
> > > are set.
> > >
> >
> > I also tried to run perf top during pgbench and get some interesting
> > results.
> >
> > Without 5364b357:
> > 5,69% postgres [.] GetSnapshotData
> > 4,47% postgres [.] LWLockAttemptLock
> > 3,81% postgres [.] _bt_compare
> > 3,42% postgres [.] hash_search_with_hash_value
> > 3,08% postgres [.] LWLockRelease
> > 2,49% postgres [.] PinBuffer.isra.3
> > 1,58% postgres [.] AllocSetAlloc
> > 1,17% [kernel] [k] __schedule
> > 1,15% postgres [.] PostgresMain
> > 1,13% libc-2.17.so [.] vfprintf
> > 1,01% libc-2.17.so [.] __memcpy_ssse3_back
> >
> > With 5364b357:
> > 18,54% postgres [.] GetSnapshotData
> > 3,45% postgres [.] LWLockRelease
> > 3,27% postgres [.] LWLockAttemptLock
> > 3,21% postgres [.] _bt_compare
> > 2,93% postgres [.] hash_search_with_hash_value
> > 2,00% postgres [.] PinBuffer.isra.3
> > 1,32% postgres [.] AllocSetAlloc
> > 1,10% libc-2.17.so [.] vfprintf
> >
> > Very surprising. It appears that after 5364b357, GetSnapshotData
> consumes
> > more time. But I can't see anything depending on clog buffers
> > in GetSnapshotData code...
>
> Could you retry after applying the attached series of patches?
>

Yes, I will try with these patches and snapshot too old reverted.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2016-04-11 14:22:48 Re: Some other things about contrib/bloom and generic_xlog.c
Previous Message Alexander Korotkov 2016-04-11 14:03:40 Re: Move PinBuffer and UnpinBuffer to atomics