Jan Wieck" <[EMAIL PROTECTED]> > > 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings