Re: Improving connection scalability: GetSnapshotData()

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2020-09-08T09:27:35Z
Lists: pgsql-hackers

On 07.09.2020 23:45, Andres Freund wrote:
> Hi,
>
>
> On Mon, Sep 7, 2020, at 07:20, Konstantin Knizhnik wrote:
>>>> And which pgbench database scale factor you have used?
>>> 200
>>>
>>> Another thing you could try is to run 2-4 pgench instances in different
>>> databases.
>> I tried to reinitialize database with scale 200 but there was no
>> significant improvement in performance.
> If you're replying to the last bit I am quoting, I was talking about having four databases with separate pbench tables etc. To see how much of it is procarray contention, and how much it is contention of common buffers etc.
>
Sorry, I have tested hypothesis that the difference in performance in my 
and you cases can be explained by size of the table which can have 
influence on shared buffer  contention.
Thus is why I used the same scale as you, but there is no difference 
compatring with scale 100.

And definitely Postgres performance in this test is limited by lock 
contention (most likely shared buffers locks, rather than procarray locks).
If I create two instances of postgres, both with pgbench -s 200 database 
and run two pgbenches with 100 connections each, then
each instance shows the same ~1million TPS (1186483) as been launched 
standalone. And total TPS is 2.3 millions.

>> Attachments:
>> * pgbench.svg
> What numactl was used for this one?
>
None. I have not used numactl in this case.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




Commits

  1. Try to unbreak 021_row_visibility.pl on mingw.

  2. Fix and test snapshot behavior on standby.

  3. Fix race condition in snapshot caching when 2PC is used.

  4. snapshot scalability: cache snapshots using a xact completion counter.

  5. Fix use of wrong index in ComputeXidHorizons().

  6. Make vacuum a bit more verbose to debug BF failure.

  7. snapshot scalability: Introduce dense array of in-progress xids.

  8. snapshot scalability: Move PGXACT->vacuumFlags to ProcGlobal->vacuumFlags.

  9. snapshot scalability: Move subxact info to ProcGlobal, remove PGXACT.

  10. snapshot scalability: Move PGXACT->xmin back to PGPROC.

  11. snapshot scalability: Don't compute global horizons while building snapshots.

  12. BRIN: Handle concurrent desummarization properly

  13. Track latest completed xid as a FullTransactionId.

  14. Rename VariableCacheData.nextFullXid to nextXid.

  15. snapshot scalability: Move delayChkpt from PGXACT to PGPROC.

  16. Report progress of CREATE INDEX operations