From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(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 08:03:38 |
Message-ID: | CAA4eK1JiOOKN73yC3rHqF_F+yKEFfn15Gh9iitT-=7Q5BuCs=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 5, 2016 at 12:05 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> 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).
>
That appears positive.
> 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
>
Are the above results with synchronous_commit=off?
> I haven't done much more testing (e.g. with -N to eliminate collisions on
> branches) yet, let's see if it changes anything.
>
Yeah, let us see how it behaves with -N. Also, I think we could try
at higher scale factor?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2016-10-05 08:13:23 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Rajkumar Raghuwanshi | 2016-10-05 07:57:58 | Re: Declarative partitioning - another take |