From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: fix lock contention for HASHHDR.mutex |
Date: | 2015-12-15 12:25:13 |
Message-ID: | 20151215122513.GC17724@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2015-12-15 12:46:29 | Re: [PATCH] Logical decoding support for sequence advances |
Previous Message | Andres Freund | 2015-12-15 12:17:02 | Re: [PATCH] Logical decoding support for sequence advances |