Date: Tue, 15 Dec 2015 13:25:13 +0100
From: Andres Freund <andres@anarazel.de>
To: Aleksander Alekseev <a.alekseev@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Message-ID: <20151215122513.GC17724@alap3.anarazel.de>
References: <20151211170001.78ded9d7@fujitsu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151211170001.78ded9d7@fujitsu>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2015-12-11 17:00:01 +0300, Aleksander Alekseev wrote:
> The problem is that code between LWLockAcquire (lock.c:881) and
> LWLockRelease (lock.c:1020) can _sometimes_ run up to 3-5 ms. Using
> old-good gettimeofday and logging method I managed to find a bottleneck:
> 
> -- proclock = SetupLockInTable [lock.c:892]
>  `-- proclock = (PROCLOCK *) hash_search_with_hash_value [lock.c:1105]
>    `-- currBucket = get_hash_entry(hashp) [dynahash.c:985]
>      `-- SpinLockAcquire(&hctl->mutex) [dynahash.c:1187]
> 
> If my measurements are not wrong (I didn't place gettimeofday between
> SpinLockAquire/SpinLockRelease, etc) we sometimes spend about 3 ms here
> waiting for a spinlock, which doesn't seems right.

Well, it's quite possible that your process was scheduled out, while
waiting for that spinlock. Which'd make 3ms pretty normal.

I'd consider using a LWLock instead of a spinlock here. I've seen this
contended in a bunch of situations, and the queued behaviour, combined
with directed wakeups on the OS level, ought to improve the worst case
behaviour measurably.

Greetings,

Andres Freund


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