Re: Patch: fix lock contention for HASHHDR.mutex - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Patch: fix lock contention for HASHHDR.mutex
Date
Msg-id CAFiTN-vJ2M1tn0yrFsOUn1-anQfzpB2n1SyEA_PBu4zk4KCe_w@mail.gmail.com
Whole thread Raw
In response to Re: Patch: fix lock contention for HASHHDR.mutex  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Responses Re: Patch: fix lock contention for HASHHDR.mutex  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
List pgsql-hackers
On Tue, Jan 12, 2016 at 1:50 PM, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote:

increasing number of lock partitions (see columns "no locks", "lwlock"
and "spinlock array"). Previously it couldn't help us (see "master"
column) because of a bottleneck.

If you have any other questions regarding this patch please don't
hesitate to ask.

I have done some performance bench marking for this patch.(dynahash-optimization-v10-step1.patch)

Machine Detail:
cpu   : POWER8
cores: 24 (192 with HT)

Non Default Parameter:
------------------------
Shared Buffer= 30GB
max_wal_size= 10GB
max_connections=500

Test1:
schema.sql and pgbench.sql are same files which Aleksander has attached in first mail of the thread.

psql -d postgres -f schema.sql
pgbench -c$ -j$ -f pgbench.sql  postgres

client    base    patch
1    145    145
2    262    258
4    453    472
8    749    732
16    1114    1128
32    1727    1789
64    2729    2793
128    3534    3520

With this test i did not see any improvement, though i think it should improve the performance, do you have any suggestion to see the results same as yours ?

I have also dump stacks using some script and I have observed many stacks dumps as you mentioned in initial thread. And after patch, I found that number of lock waiting stacks are reduced.

Stack Dump:
-------------------
#0  0x00007f25842899a7 in semop () from /lib64/libc.so.6
#1  0x00000000007116d0 in PGSemaphoreLock (sema=0x7f257cb170d8) at pg_sema.c:387
#2  0x000000000078955f in LWLockAcquire (lock=0x7f247698a980, mode=LW_EXCLUSIVE) at lwlock.c:1028
#3  0x00000000007804c4 in LockAcquireExtended
#4  0x000000000077fe91 in LockAcquire
#5  0x000000000077e862 in LockRelationOid
#6  0x000000000053bc7b in find_inheritance_children
#7  0x000000000053bd4f in find_all_inheritors
#8  0x00000000006fc0a2 in expand_inherited_rtentry
#9  0x00000000006fbf91 in expand_inherited_tables

I have tried to analyze using perf also, I can see that amount of time taken in hash_search_with_hash_value is reduced from 3.86%(master) to 1.72%(patch).

I have plan to do further investigation, in different scenarios of dynahash.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Marcin Mańk
Date:
Subject: Re: Releasing in September
Next
From: Ashutosh Bapat
Date:
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)