Re: Proposal for CSN based snapshots

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)2ndquadrant(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, Ants Aasma <ants(at)cybertec(dot)at>, Bruce Momjian <bruce(at)momjian(dot)us>, obartunov <obartunov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>
Subject: Re: Proposal for CSN based snapshots
Date: 2016-08-23 13:35:51
Message-ID: CAA4eK1LZwyH-BMBa45C4xMaBM0O99N+3O050S4+bUjofFuk60w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 22, 2016 at 11:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Aug 22, 2016 at 1:32 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> But what about the best case? If we create a scenario where there are
>>> no open read-write transactions at all and (somehow) lots and lots of
>>> ProcArrayLock contention, how much does this help?
>>
>> I ran some quick pgbench tests on my laptop, but didn't see any meaningful
>> benefit. I think the best I could see is about 5% speedup, when running
>> "pgbench -S", with 900 idle connections sitting in the background. On the
>> positive side, I didn't see much slowdown either. (Sorry, I didn't record
>> the details of those tests, as I was testing many different options and I
>> didn't see a clear difference either way.)
>
> That's not very exciting.
>
>> It seems that Amit's PGPROC batch clearing patch was very effective. I
>> remember seeing ProcArrayLock contention very visible earlier, but I can't
>> hit that now. I suspect you'd still see contention on bigger hardware,
>> though, my laptop has oly 4 cores. I'll have to find a real server for the
>> next round of testing.
>
> It's good that those patches were effective, and I bet that approach
> could be further refined, too. However, I think Amit may have
> mentioned in an internal meeting that he was able to generate some
> pretty serious ProcArrayLock contention with some of his hash index
> patches applied. I don't remember the details, though.
>

Yes, thats right. We are seeing ProcArrayLock as a bottleneck at
high-concurrency for hash-index reads. On a quick look, it seems
patch still acquires ProcArrayLock in shared mode in GetSnapshotData()
although duration is reduced. I think it is worth to try the workload
where we are seeing ProcArrayLock as bottleneck, but not sure if it
can drastically improves the situation, because as per our initial
analysis, lock acquisition and release itself causes problem.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-08-23 13:50:36 Re: Block level parallel vacuum WIP
Previous Message Jim Nasby 2016-08-23 13:26:58 Re: Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)