On 06/10/2015 10:59 AM, Robert Haas wrote:
On Wed, Jun 10, 2015 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Jan Wieck <j...@wi3ck.info> writes:
The attached patch demonstrates that less aggressive spinning and (much)
more often delaying improves the performance "on this type of machine".
Hm. One thing worth asking is why the code didn't converge to a good
value of spins_per_delay without help. The value should drop every time
we had to delay, so under heavy contention it ought to end up small
anyhow, no? Maybe we just need to alter the feedback loop a bit.
(The comment about uniprocessors vs multiprocessors seems pretty wacko in
this context, but at least the sign of the feedback term seems correct.)
The code seems to have been written with the idea that we should
converge to MAX_SPINS_PER_DELAY if spinning *ever* works. The way
that's implemented is that, if we get a spinlock without having to
delay, we add 100 to spins_per_delay, but if we have to delay at least
once (potentially hundreds of times), then we subtract 1.
spins_per_delay will be >900 most of the time even if only 1% of the
lock acquisitions manage to get the lock without delaying.
And note that spins_per_delay is global. Getting ANY lock without delay
adds 100, regardless of that being a high or low contented one. Your
process only needs to hit one low contention slock every 100 calls to
securely peg this value >=900.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
