Date: Fri, 22 Jan 2016 13:14:32 +0300
From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Message-ID: <20160122131432.2f11dac4@fujitsu>
In-Reply-To: 
 <CAFiTN-vJ2M1tn0yrFsOUn1-anQfzpB2n1SyEA_PBu4zk4KCe_w@mail.gmail.com>
References: <20151230160137.034371e0@fujitsu>
 <20160112001642.GA802875@alvherre.pgsql>
 <20160112112005.26675392@fujitsu>
 <CAFiTN-vJ2M1tn0yrFsOUn1-anQfzpB2n1SyEA_PBu4zk4KCe_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

This patch affects header files. By any chance didn't you forget to run
`make clean` after applying it? As we discussed above, when you
change .h files autotools doesn't rebuild dependent .c files:

http://www.postgresql.org/message-id/CAF4Au4y4MTapP2u3uGtBQd_z0CHEsJWfNAvRgK4umfcWA4ELxQ@mail.gmail.com

On Thu, 21 Jan 2016 16:49:12 +0530
Dilip Kumar <dilipbalaut@gmail.com> wrote:

> 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.
> 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers