Re: patch: improve SLRU replacement algorithm

From: Greg Stark <stark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: improve SLRU replacement algorithm
Date: 2012-04-04 22:30:51
Message-ID: CAM-w4HNMf-tAZRVuVwgmrxRqLXJFJ47f-XkFh+QLxwSpTbM=CA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 4, 2012 at 9:05 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Here's a sample of how often that's firing, by second, on
> this test (pgbench with 32 clients):
>
>   4191 19:54:21
>   4540 19:54:22

Hm, so if that's evenly spread out that's 1/4ms between slru flushes
and if each flush takes 5-10ms that's going to be 20-40 flushes
concurrently going on.

I'm curious to see a distribution of how many flushes are already
concurrently happening whenever a flush is initiated. This should be
possible to get by counting the number of pages that were skipped in
your patch as it went through the slru.

Also, oops, sorry. I mixed up the 32 clog buffers with the 16 files
that the slru.c remembers during a flush to fsync later. I still don't
understand why it doesn't just allocate enough space to remember to
fsync the worst case which is one file per clog buffer though which
would only be twice as many.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-04 22:41:00 Re: Speed dblink using alternate libpq tuple storage
Previous Message Greg Stark 2012-04-04 22:22:46 Re: patch: improve SLRU replacement algorithm