Re: patch: improve SLRU replacement algorithm - Mailing list pgsql-hackers

From Greg Stark
Subject Re: patch: improve SLRU replacement algorithm
Date
Msg-id CAM-w4HNd5oTJom0MX6V7ABdN5x5xeULbCWwg80+WUWWwQoL+VA@mail.gmail.com
Whole thread Raw
In response to patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: log chunking broken with large queries under load
Next
From: Alvaro Herrera
Date:
Subject: Re: patch: improve SLRU replacement algorithm