Re: Speed up Clog Access by increasing CLOG buffers

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speed up Clog Access by increasing CLOG buffers
Date: 2016-10-05 06:35:19
Message-ID: 3cc206fa-7d36-f020-3856-12ed405e2535@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

After collecting a lot more results from multiple kernel versions, I can
confirm that I see a significant improvement with 128 and 192 clients,
roughly by 30%:

64 128 192
------------------------------------------------
master 62482 43181 50985
granular-locking 61701 59611 47483
no-content-lock 62650 59819 47895
group-update 63702 64758 62596

But I only see this with Dilip's workload, and only with pre-4.3.0
kernels (the results above are from kernel 3.19).

With 4.5.5, results for the same benchmark look like this:

64 128 192
------------------------------------------------
master 35693 39822 42151
granular-locking 35370 39409 41353
no-content-lock 36201 39848 42407
group-update 35697 39893 42667

That seems like a fairly bad regression in kernel, although I have not
identified the feature/commit causing it (and it's also possible the
issue lies somewhere else, of course).

With regular pgbench, I see no improvement on any kernel version. For
example on 3.19 the results look like this:

64 128 192
------------------------------------------------
master 54661 61014 59484
granular-locking 55904 62481 60711
no-content-lock 56182 62442 61234
group-update 55019 61587 60485

I haven't done much more testing (e.g. with -N to eliminate collisions
on branches) yet, let's see if it changes anything.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2016-10-05 07:57:58 Re: Declarative partitioning - another take
Previous Message Michael Paquier 2016-10-05 06:18:53 Re: Fix checkpoint skip logic on idle systems by tracking LSN progress