From: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: Cache data in GetSnapshotData() |
Date: | 2016-03-18 10:54:31 |
Message-ID: | CAD__Ouh6PahJ+q1mzzjDzLo4v9GjyufegtJNAyXc0_Lfh-4coQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 17, 2016 at 9:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
>If you see, for the Base readings, there is a performance increase up till
64 clients and then there is a fall at 88 clients, which to me >indicates
that it hits very high-contention around CLogControlLock at 88 clients
which CLog patch is able to control to a great degree (if >required, I
think the same can be verified by LWLock stats data). One reason for
hitting contention at 88 clients is that this machine >seems to have
64-cores (it has 8 sockets and 8 Core(s) per socket) as per below
information of lscpu command.
I am attaching LWLock stats data for above test setups(unlogged tables).
*BASE* At 64 clients Block-time unit At 88 clients Block-time unit
ProcArrayLock 182946 117827
ClogControlLock 107420 120266
*clog patch*
ProcArrayLock 183663 121215
ClogControlLock 72806 65220
*clog patch + save snapshot*
ProcArrayLock 128260 83356
ClogControlLock 78921 74011
This is for unlogged lables, I mainly see ProcArrayLock have higher
contention at 64 clients and at 88 contention is slightly moved to other
entities.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
lwlock details.odt | application/vnd.oasis.opendocument.text | 26.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-03-18 11:17:28 | Re: Odd system-column handling in postgres_fdw join pushdown patch |
Previous Message | Etsuro Fujita | 2016-03-18 10:40:30 | Re: Odd system-column handling in postgres_fdw join pushdown patch |