Re: StrategyGetBuffer questions

On Tue, Nov 20, 2012 at 4:50 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 1:26 PM, Merlin Moncure <mmoncure@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.

Ah, interesting. well, that's more aggressive in that you dispense
with the lwlock completely.  hm.

merlin