On Wed, Aug 30, 2017 at 2:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jul 4, 2017 at 12:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> I have updated the patch to support wait events and moved it to upcoming CF.
>
> This patch doesn't apply any more, but I made it apply with a hammer
> and then did a little benchmarking (scylla, EDB server, Intel Xeon
> E5-2695 v3 @ 2.30GHz, 2 sockets, 14 cores/socket, 2 threads/core).
> The results were not impressive. There's basically no clog contention
> to remove, so the patch just doesn't really do anything.
>
Yeah, in such a case patch won't help.
> For example,
> here's a wait event profile with master and using Ashutosh's test
> script with 5 savepoints:
>
> 1 Lock | tuple
> 2 IO | SLRUSync
> 5 LWLock | wal_insert
> 5 LWLock | XidGenLock
> 9 IO | DataFileRead
> 12 LWLock | lock_manager
> 16 IO | SLRURead
> 20 LWLock | CLogControlLock
> 97 LWLock | buffer_content
> 216 Lock | transactionid
> 237 LWLock | ProcArrayLock
> 1238 IPC | ProcArrayGroupUpdate
> 2266 Client | ClientRead
>
> This is just a 5-minute test; maybe things would change if we ran it
> for longer, but if only 0.5% of the samples are blocked on
> CLogControlLock without the patch, obviously the patch can't help
> much. I did some other experiments too, but I won't bother
> summarizing the results here because they're basically boring. I
> guess I should have used a bigger machine.
>
That would have been better. In any case, will do the tests on some
higher end machine and will share the results.
> Given that we've changed the approach here somewhat, I think we need
> to validate that we're still seeing a substantial reduction in
> CLogControlLock contention on big machines.
>
Sure will do so. In the meantime, I have rebased the patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers