Re: Disabling bgwriter on my notebook

Jan Wieck" <JanWieck(at)Yahoo(dot)com>
> > Aside from that I don't believe that the output can answer questions
about
> > the efficiency of bgwriter...
> >
> > DEBUG: ARC T1target= 194 B1len= 779 T1len= 180 T2len= 820 B2len=
208
> > DEBUG: ARC total = 99% B1hit= 18% T1hit= 6% T2hit= 75% B2hit=
0%
> > DEBUG: ARC clean buffers at LRU T1= 180 T2= 820
>
> Look at the last line about clean buffers at LRU. This shows that you
> currently don't have ANY dirty buffers, as the number of clean buffers
> in T1 and T2 is identical to the two queue lengths.

Ah, now suddenly the output seems much clearer. Thanks! :-)

> The bgwriter always flushes the oldest dirty buffers, and every buffer
> touched (hit or faulted in). The output above doesn't tell you how many
> buffers are really dirty. But if the system is under load, that is
> pretty much the same as the distance between those numbers.

That would be nice, since analysing ARC/bgwriter using the logs would be
much easier, if it really wrote those in constant intervals independent of
backend activity.

> > bgwriter_delay = 50 (now default 200)
> > bgwriter_percent = 2 (now default 1)
> > bgwriter_maxpages = 200 (now default 100)
>
> Just what I was having the best TPC-C results with.

And how were the default values in chosen? Educated guesses?

Best Regards,
Michael Paesold