Bufwaits and tuning

Configuration: IDS 7.30.uc7 HPUX 10.20 Associated parameters: BUFFERS 50000 LRUS 8 CLEANERS 8 LRU_MAX_DIRTY 8 LRU_MIN_DIRTY 4 RA_PAGES 64 RA_THRESHOLD 32 I've set aside some time for tuning (refining?) and wanted to experiment with my LRU settings in order to decrease bufwaits. I've recently enabled my read-ahead parameters and noticed an increase in bufwaits, probably due to increased buffer activity. I like my read-aheads; I've gotten some of my performance back from the old 7.2x days. As a test, I kicked off a bunch of batch reports; most of them access the same table, just different records within the table. I've been monitoring the disks; no contention that I can see with glance and iostat. After the first test, I noticed a high percentage of bufwaits (close to 100% of (dskreads+bufwrits)/bufwaits). I then set LRUS and CLEANERS to 32 (CLEANERS shouldn't make much different for reports), bounced Informix, and restarted the reports. They've been running for a while now, but I've noticed that my bufwaits percentage ( (dskreads+bufwrits) / bufwaits ) has gone through the roof (224% currently). I'm obviously not understanding the relationships here. Based on prevoius posts, I know that bufwaits are a result of a thread attempting to lock a buffer and being unable to do so. But increasing LRUs should have a good impact on that situation, hmmmmmm?

Your calculation is backwards that (bufwaits/(dskreads+bufwrits)) which is still 44% (1/2.24) and not too good. Try a value which is not a power of 2. Menlo says they changed the LRU algorithm to get around the problem I reported, which they cannot duplicate and which they claim does not exist, in 7.3x. Perhaps they just broke it worse and 32 is now a node. Art S. Kagel "Carlson@WHSmith" wrote: > > Configuration: > IDS 7.30.uc7 > HPUX 10.20 > > Associated parameters: > BUFFERS 50000 > LRUS 8 > CLEANERS 8 > LRU_MAX_DIRTY 8 > LRU_MIN_DIRTY 4 > RA_PAGES 64 > RA_THRESHOLD 32> > I've set aside some time for tuning (refining?) and wanted to experiment > with my LRU settings in order to decrease bufwaits. I've recently > enabled my read-ahead parameters and noticed an increase in bufwaits, > probably due to increased buffer activity. I like my read-aheads; I've > gotten some of my performance back from the old 7.2x days. > > As a test, I kicked off a bunch of batch reports; most of them access > the same table, just different records within the table. I've been > monitoring the disks; no contention that I can see with glance and > iostat. After the first test, I noticed a high percentage of bufwaits > (close to 100% of (dskreads+bufwrits)/bufwaits). > > I then set LRUS and CLEANERS to 32 (CLEANERS shouldn't make much > different for reports), bounced Informix, and restarted the reports. > They've been running for a while now, but I've noticed that my bufwaits > percentage ( (dskreads+bufwrits) / bufwaits ) has gone through the roof > (224% currently). > > I'm obviously not understanding the relationships here. Based on > prevoius posts, I know that bufwaits are a result of a thread attempting > to lock a buffer and being unable to do so. But increasing LRUs should > have a good impact on that situation, hmmmmmm?

As long as I'm heading down the right path . . . I've been a part of this newsgroup for a bit and have come to believe that a change such as this would increase performance in various areas. I was expecting a drastic change in performance, etc., just not THAT one. Thanks John Carlson Informix DBA WHSmith USA Art S. Kagel wrote: > > Your calculation is backwards that (bufwaits/(dskreads+bufwrits)) which > is still 44% (1/2.24) and not too good. Try a value which is not a > power of 2. Menlo says they changed the LRU algorithm to get around > the problem I reported, which they cannot duplicate and which they > claim does not exist, in 7.3x. Perhaps they just broke it worse and 32 > is now a node. > > Art S. Kagel > > "Carlson@WHSmith" wrote: > > > > Configuration: > > IDS 7.30.uc7 > > HPUX 10.20 > > > > Associated parameters: > > BUFFERS 50000 > > LRUS 8 > > CLEANERS 8 > > LRU_MAX_DIRTY 8 > > LRU_MIN_DIRTY 4 > > RA_PAGES 64 > > RA_THRESHOLD 32> > > > I've set aside some time for tuning (refining?) and wanted to experiment > > with my LRU settings in order to decrease bufwaits. I've recently > > enabled my read-ahead parameters and noticed an increase in bufwaits, > > probably due to increased buffer activity. I like my read-aheads; I've > > gotten some of my performance back from the old 7.2x days. > > > > As a test, I kicked off a bunch of batch reports; most of them access > > the same table, just different records within the table. I've been > > monitoring the disks; no contention that I can see with glance and > > iostat. After the first test, I noticed a high percentage of bufwaits > > (close to 100% of (dskreads+bufwrits)/bufwaits). > > > > I then set LRUS and CLEANERS to 32 (CLEANERS shouldn't make much > > different for reports), bounced Informix, and restarted the reports. > > They've been running for a while now, but I've noticed that my bufwaits > > percentage ( (dskreads+bufwrits) / bufwaits ) has gone through the roof > > (224% currently). > > > > I'm obviously not understanding the relationships here. Based on > > prevoius posts, I know that bufwaits are a result of a thread attempting > > to lock a buffer and being unable to do so. But increasing LRUs should > > have a good impact on that situation, hmmmmmm?