Jan Wieck" <JanWieck@Yahoo.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
