From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Teodor Sigaev <teodor@sigaev.ru>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Date: Tue, 12 Jan 2016 11:20:05 +0300
Message-ID: <20160112112005.26675392@fujitsu> (raw)
In-Reply-To: <20160112001642.GA802875@alvherre.pgsql>
References: <20151230160137.034371e0@fujitsu>
<20160112001642.GA802875@alvherre.pgsql>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hello, Álvaro
> So you were saying some posts upthread that the new hash tables would
> "borrow" AN elements from the freelist then put AN elements back when
> too many got unused. Is that idea embodied in this patch?
Right. It didn't satisfy "use all memory" requirement anyway. It's
better to sacrifice a few TPS (according only to my benchmark which
doesn't represent all possible use cases) than accidentally break
someones system after upgrading to the next version of PostgreSQL. See
example with pg_dump given by Robert Haas above.
>> +/* Number of partitions of the shared buffer mapping hashtable */
>> +#define NUM_BUFFER_PARTITIONS NUM_LOCK_PARTITIONS
>> +
>> /* Number of partitions the shared predicate lock tables are divided
>> into */ #define LOG2_NUM_PREDICATELOCK_PARTITIONS 4
>> #define NUM_PREDICATELOCK_PARTITIONS (1 <<
>> LOG2_NUM_PREDICATELOCK_PARTITIONS)
>
> I find this odd. Why is it a good idea to define the bufMapping
> partitions like this? What's the explanation for the performance
> numbers you saw?
My mistake. I thought that last table was self-explanatory.
We see that a single spinlock for accessing a freeList (current
implementation) is obviously a bottleneck. Replacing it with say an
array of spinlocks reduces lock contention and therefore gives more TPS
(see first row). Also we can increase concurrency level even further by
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.
Best regards,
Aleksander
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.alekseev@postgrespro.ru, alvherre@2ndquadrant.com, robertmhaas@gmail.com, teodor@sigaev.ru, andres@anarazel.de
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
In-Reply-To: <20160112112005.26675392@fujitsu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox