From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Log levels for checkpoint/bgwriter monitoring |
Date: | 2007-03-09 02:04:58 |
Message-ID: | 20070309104251.6341.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> > Also, my recommended bgwriter_lru_maxpages is "average number of
> > recycled buffers per cycle", that is hardly able to tune manually.
>
> This is completely dependent on what percentage of your buffer cache is
> pinned.
Don't you mean usage_count? In my understanding, each backend pins two
or so buffers at once. So percentage of pinned buffers should be low.
> If your load is something like the standard pgbench, the LRU
> writer will rarely find anything useful to write, so this entire line of
> thinking won't work. The proper behavior for heavily pinned data is to
> turn off the LRU writer altogether so there's more time to run the all
> scan.
I think you are pointing out the problem of buffer management algorithm
itself, not only bgwriter. Even if you turn off the LRU writer, each
backend pays the same cost to find recyclable buffers every time they
allocate a buffer.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-09 05:42:41 | Re: RFC: changing autovacuum_naptime semantics |
Previous Message | ITAGAKI Takahiro | 2007-03-09 01:42:13 | Re: Log levels for checkpoint/bgwriter monitoring |