Re: onconfig advise please
"Art S. Kagel" wrote: > More LRUS & CLEANERS your BR is 25% more than 4X normal, you are running on Art, I have read the term "BR" from you many times, but I've never discover what does it mean ? How do you calculate it ? It seems to be one of most important thing in tuning IDS performance... Thanks you, Michal Hajek -- -------------------------------------------------------------- Michal Hajek mailto:hajek@nspuh.cz --------------------------------------------------------------
Michal Hajek wrote: > > "Art S. Kagel" wrote: > > More LRUS & CLEANERS your BR is 25% more than 4X normal, you are running on > > Art, I have read the term "BR" from you many times, but I've never > discover what does it mean ? > How do you calculate it ? It seems to be one of most important > thing in tuning IDS performance... BR is Bufwaits Ratio (aka KBR for Kagel's Bufwaits Ratio and while I'm vain enough to mention that I won't use it, okay I won't use it anymore ;0). BR = (bufwaits / (pagreads + bufwrits)) * 100.00% In tries to quantify the percentage of the engine's attempts to acquire a latch on an LRU queue has had to spin indicated by bufwaits. Note that bufwaits also indicates spins waiting for a buffer latch also. Informix claims the latter are far more common than LRU latch waits but experience shows that the level of buffer latch waits is constant (about 3-6% out of the BR's normal 7%) and that the variable part that is most load dependent are the LRU latch waits. BR values below 7% tend to indicate a well tuned server as far as buffer and LRU contention is concerned. Values between 7 and 10% indicate there is some unusual level of contention causing performance degradation and values above 10% are indicative of a deadly level of contention usually for LRU access. By looking at ovbuff and the BTR (Buffer Turnover Rate) or BTF (Buffer Turnover Frequency) you can determine whether the problem is not enough buffers or LRU contention. If LRU contention increase LRUS and CLEANERS if possible, if they are already maxed out (128 on 7.x/9.x, 256 on 8.x) then look into using the undocumented ONCONFIG parameter LRUPOLICY to cause each client process to favor a single LRU queue (see my post on the subject around May or June). Art S. Kagel
> By looking at ovbuff and the BTR (Buffer Turnover Rate) or BTF (Buffer > Turnover Frequency) you can determine whether the problem is not enough > buffers or LRU contention. If LRU contention increase LRUS and CLEANERS if > possible, if they are already maxed out (128 on 7.x/9.x, 256 on 8.x) then > look into using the undocumented ONCONFIG parameter LRUPOLICY to cause each > client process to favor a single LRU queue (see my post on the subject > around May or June). Hi Art, could you post it again please? I could not find it any more. And could you please explain what the other two subjects mean? BTR (Buffer Turnover Rate) or BTF (Buffer Turnover Frequency) Many thanks Peter -- Peter Dzvonyar SAP-Consultant R/3 BC _______________________________________________________________ email: sap-ext-001@ops.de p.dzvonyar@t-online.de _______________________________________________________________
I was in a reply I posted on June 6, 2000, see: www.iiug.org/members/cdi_archive/2000.06/cdii.60789 Art S. Kagel Peter Dzvonyar wrote: > > > By looking at ovbuff and the BTR (Buffer Turnover Rate) or BTF (Buffer > > Turnover Frequency) you can determine whether the problem is not enough > > buffers or LRU contention. If LRU contention increase LRUS and CLEANERS if > > possible, if they are already maxed out (128 on 7.x/9.x, 256 on 8.x) then > > look into using the undocumented ONCONFIG parameter LRUPOLICY to cause each > > client process to favor a single LRU queue (see my post on the subject > > around May or June). > > Hi Art, > > could you post it again please? I could not find it any more. > And could you please explain what the other two subjects mean? BTR (Buffer Turnover > Rate) or BTF (Buffer > Turnover Frequency) > > Many thanks > Peter > -- > Peter Dzvonyar > SAP-Consultant R/3 BC > _______________________________________________________________ > > email: sap-ext-001@ops.de p.dzvonyar@t-online.de > _______________________________________________________________