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
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 |