Re: patch: improve SLRU replacement algorithm

On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 3. I noticed that the blocking described by "slru.c:311 blocked by
> slru.c:405" seemed to be clumpy - I would get a bunch of messages
> about that all at once.  This makes me wonder if the SLRU machinery is
> occasionally making a real bad decision about what page to evict, and
> then everybody piles up waiting for that page to be read back in.
> That is sheer hand-waving at this point and might be complete bologna,
> but I'm hoping to find time to investigate further.

Hm, actually, isn't this something your patch would cause? Is it
possible the clumpy ones are the 129 minus 54 additional blocking on this
lock in the patched code? Did it do that in the unpatched code? And
did it do it with fewer than 16 clients?

Because there are only 16 slru pages and 64 clients so occasionally 16
of clients will all be reading a page in and someone will try to flush
the very hottest page from the slru. Or I suppose it would happen
sooner as soon as someone gets pushed up into the working set and hits
a hot enough page.

i didn't actually read the patch. I assume you covered the case where
all the pages are in I/O and so there are no eligible pages to flush?

--
greg