Re: RA, bugs, and performance

Art S. Kagel wrote: > > Carlson@WHSmith wrote: > > > > > As part of my tuning, I was planning to revisit these variables. Where > > would be a good trade-off between read-aheads and bufwaits? I've seen > > the postings by various people, and took them to heart for the next > > round of R&D testing on my test system. > > The RA parameters do not affect bufwaits. Bufwaits are caused by a > thread having to wait for an LRU to unlock so it can write to a BUFFER. > It is caused by too few LRUS or just a busy system (or a suspected bug > related to how processes select the next LRU if they have to wait too > long for the LRU to unlock which happens when LRUS in (16,64,96)). > OK . . . big oops on my part. I took a quick look at all of the information to date and got my read-ahead articles confused with my bufwait articles. LRUs are currently set to 8. > > Unfortunately, bug# 85350 changed all of that. > > Have not heard of that one. Please elaborate. > Boy am I full of errors today. The bug number should be 57338. (I've been hitting bugs right and left lately.) The bug reports that the buffer is not locked by read_ahead when RA_PAGES > 0. > > I now have reset these parameters to 0. While I didn't mind retuning > > these variables, I hadn't planned on resetting them quite like this. > > Oh NO! > Something about the best laid plans of mice and men . . . > > Any idea of what the impact to my system would be? We're a mixed > > environment, OLTP and DSS batch reporting. > > Increased stress on the I/O subsystems, especially if the server is > very busy. If the server is dedicated, and not already running close > to capacity, you may not notice. If you have to share the machine with > other apps there will probably be degradation in both server performance > and that of the other residents. > I was afraid that you'd say that. Oh, well . . . . John Carlson Informix DBA WH Smith, Inc.