From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: fix lock contention for HASHHDR.mutex |
Date: | 2016-01-21 11:19:12 |
Message-ID: | CAFiTN-vJ2M1tn0yrFsOUn1-anQfzpB2n1SyEA_PBu4zk4KCe_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 12, 2016 at 1:50 PM, Aleksander Alekseev <
a(dot)alekseev(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-01-21 13:36:24 | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |
Previous Message | Marcin Mańk | 2016-01-21 11:11:41 | Re: Releasing in September |