On Tue, Nov 20, 2012 at 1:26 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > In this sprawling thread on scaling issues [1], the topic meandered > into StrategyGetBuffer() -- in particular the clock sweep loop. I'm > wondering: > > *) If there shouldn't be a a bound in terms of how many candidate > buffers you're allowed to skip for having a non-zero usage count. > Whenever an unpinned usage_count>0 buffer is found, trycounter is > reset (!) so that the code operates from point of view as it had just > entered the loop. There is an implicit assumption that this is rare, > but how rare is it?
How often is that the trycounter would hit zero if it were not reset? I've instrumented something like that in the past, and could only get it to fire under pathologically small shared_buffers and workloads that caused most of them to be pinned simultaneously. > *) Shouldn't StrategyGetBuffer() bias down usage_count if it finds > itself examining too many unpinned buffers per sweep? It is a self correcting problem. If it is examining a lot of unpinned buffers, it is also decrementing a lot of them. > > *) Since the purpose of usage_count is to act on advisory basis to > keep recently/frequently accessed buffers from being discarded, is it > really necessary to rigorously guard the count with a spinlock? If a > ++ or -- operation on the value gets missed here or there, how big of > a deal is it really? I don't think it is all that big of a deal. I've implemented this patch to do that. It still applies to head. http://archives.postgresql.org/pgsql-hackers/2011-08/msg00305.php It was very effective at removing BufFreelistLock contention on the system I had at the time. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
