From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Speed up Clog Access by increasing CLOG buffers
Date: Sat, 17 Sep 2016 03:24:33 +0200
Message-ID: <3bb2699f-fe51-7419-b42b-9ad5bfd0d506@2ndquadrant.com> (raw)
In-Reply-To: <CAFiTN-t-VKZTXUdOX_L_X4Nw6bXOX=Fbmm2Oq=PmD4KqCufHBQ@mail.gmail.com>
References: <CAA4eK1+8=X9mSNeVeHg_NqMsOR-XKsjuqrYzQf=iCsdh3U4EOA@mail.gmail.com>
<20150903114137.GE27649@awork2.anarazel.de>
<CAA4eK1LMMGNQ439BUm0LcS3p0sb8S9kc-cUGU_ThNqMwA8_Tug@mail.gmail.com>
<CAA4eK1+-=18HOrdqtLXqOMwZDbC_15WTyHiFruz7BvVArZPaAw@mail.gmail.com>
<20160330230914.GH13305@awork2.anarazel.de>
<CAA4eK1L2KO18G5-ajNitztnmn1G_Ex1N4oUHhF0Xx3QrY57Ufw@mail.gmail.com>
<20160408153054.hgubabeycowlu3tc@alap3.anarazel.de>
<CAA4eK1+6URLZYM+xjnvc027+mqQztWc8VDm0udY2X+bdC2HP+A@mail.gmail.com>
<8bab43dd-bc76-0c41-950e-8101269dbf4b@2ndquadrant.com>
<CAA4eK1JJOWO6u99gUMMQWELXbci428vRBbJnxg=V04NuZwBCSw@mail.gmail.com>
<CAFiTN-u3=XUi7z8dTOgxZ98E7gL1tzL=q9Yd=CwWCtTtS6pOZw@mail.gmail.com>
<CA+TgmoYO1wNi7dRwNxGUupmMPhOkae-pmU38ndC1s6FDQ-USJg@mail.gmail.com>
<CAFiTN-t-VKZTXUdOX_L_X4Nw6bXOX=Fbmm2Oq=PmD4KqCufHBQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 09/14/2016 06:04 PM, Dilip Kumar wrote:
> On Wed, Sep 14, 2016 at 8:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Sure, but you're testing at *really* high client counts here. Almost
>> nobody is going to benefit from a 5% improvement at 256 clients.
>
> I agree with your point, but here we need to consider one more thing,
> that on head we are gaining ~30% with both the approaches.
>
> So for comparing these two patches we can consider..
>
> A. Other workloads (one can be as below)
> -> Load on CLogControlLock at commit (exclusive mode) + Load on
> CLogControlLock at Transaction status (shared mode).
> I think we can mix (savepoint + updates)
>
> B. Simplicity of the patch (if both are performing almost equal in all
> practical scenarios).
>
> C. Bases on algorithm whichever seems winner.
>
> I will try to test these patches with other workloads...
>
>> You
>> need to test 64 clients and 32 clients and 16 clients and 8 clients
>> and see what happens there. Those cases are a lot more likely than
>> these stratospheric client counts.
>
> I tested with 64 clients as well..
> 1. On head we are gaining ~15% with both the patches.
> 2. But group lock vs granular lock is almost same.
>
I've been doing some testing too, but I haven't managed to measure any
significant difference between master and any of the patches. Not sure
why, I've repeated the test from scratch to make sure I haven't done
anything stupid, but I got the same results (which is one of the main
reasons why the testing took me so long).
Attached is an archive with a script running the benchmark (including
SQL scripts generating the data and custom transaction for pgbench), and
results in a CSV format.
The benchmark is fairly simple - for each case (master + 3 different
patches) we do 10 runs, 5 minutes each, for 32, 64, 128 and 192 clients
(the machine has 32 physical cores).
The transaction is using a single unlogged table initialized like this:
create unlogged table t(id int, val int);
insert into t select i, i from generate_series(1,100000) s(i);
vacuum t;
create index on t(id);
(I've also ran it with 100M rows, called "large" in the results), and
pgbench is running this transaction:
\set id random(1, 100000)
BEGIN;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s1;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s2;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s3;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s4;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s5;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s6;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s7;
UPDATE t SET val = val + 1 WHERE id = :id;
SAVEPOINT s8;
COMMIT;
So 8 simple UPDATEs interleaved by savepoints. The benchmark was running
on a machine with 256GB of RAM, 32 cores (4x E5-4620) and a fairly large
SSD array. I'd done some basic tuning on the system, most importantly:
effective_io_concurrency = 32
work_mem = 512MB
maintenance_work_mem = 512MB
max_connections = 300
checkpoint_completion_target = 0.9
checkpoint_timeout = 3600
max_wal_size = 128GB
min_wal_size = 16GB
shared_buffers = 16GB
Although most of the changes probably does not matter much for unlogged
tables (I planned to see how this affects regular tables, but as I see
no difference for unlogged ones, I haven't done that yet).
So the question is why Dilip sees +30% improvement, while my results are
almost exactly the same. Looking at Dilip's benchmark, I see he only ran
the test for 10 seconds, and I'm not sure how many runs he did, warmup
etc. Dilip, can you provide additional info?
I'll ask someone else to redo the benchmark after the weekend to make
sure it's not actually some stupid mistake of mine.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackersAttachments:
[application/x-compressed-tar] clog.tgz (4.3K, ../3bb2699f-fe51-7419-b42b-9ad5bfd0d506@2ndquadrant.com/2-clog.tgz)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, dilipbalaut@gmail.com, robertmhaas@gmail.com, amit.kapila16@gmail.com, andres@anarazel.de
Subject: Re: Speed up Clog Access by increasing CLOG buffers
In-Reply-To: <3bb2699f-fe51-7419-b42b-9ad5bfd0d506@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox