Re: How do I check LRU contention - onstat -g spi ????

It means exactly what it says it means, towit that you are recycling all of your buffers every 4 to 10 minutes (or recycling a smaller number even more frequently which is unlikely given the LRU replacement algorithm). It means that 6-14 times during each hour (aggregating both of your results) applications are looking to read pages that would have already been in cache if the cache were larger but which were likely swapped out by more recently, but perhaps less frequently, used pages. You decide how much a larger cache could have sped up those millions of page accesses! Now temper this by applying your writ cache ratio to bufwrits to get a lower bound for turnovers, the figure I calculate is an upper bound I use to detect potential problems. Using the figures Bob provides below I calculate, for the single 15 hour period: Upper bound BT = (2336746 + 8962516) / 126000 = 89.67668 Upper bound BTR = 89.68 / 15 = 5.98 Turnovers per hour Lower bound BT = ((2336746 * (1.0-0.9481) + 8962516) / 126000 = 72.09359 Lower bound BTR = 72.09 / 15 = 4.81 Turnovers per hour You can see that even a 94+% write cache percentage has little effect on the turnover calculation which is why I normally just use the upper bound calculation. These figures are probably not bad but there is ALWAYS room for improvement. To Bob's last question below, yes you might reduce the SHMVIRTSIZE and trade it for more buffers. Also your bufwaits ratio is around 5% in the figures shown here but if at other times you are seeing figures between 8 and 10% then try more LRUs and the appropriate number of CLEANERS to improve things, note that increasing BUFFERS will tend to help the BR also if the LRU contention is coming mainly during peak load for short periods so try that first. Art S. Kagel Robert Bothwell wrote: > Chris Burton wrote: > > > >Buffer Turnovers = (pagreads + bufwrits) / BUFFERS > > > > What is a 'few' time an hour. I am showing 11 times per hour with a > > buf_wait ratio of about 5%. Comments? > > > [snip] > > Chris > > I see similar numbers, though my buf_wait ratio regularly visits no-mans > land > (8-10). We're running 7.31.UC5 on a 4-way IBM H50 (332 MHZ) w/2 GB RAM, > & AIX > 4.3.2. I am seeing a turnover rate anywhere from 6 to 14 per hour. This > is 'onstat -p' > from our system running about 15 hours since the last onstat -z: > > Informix Dynamic Server Version 7.31.UC5 -- On-Line -- Up 2 days > 09:29:11 -- > 915312 Kbytes > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 7048290 8962516 472042006 98.51 605618 1379970 11671757 94.81 > > isamtot open start read write rewrite delete commit > rollbk > 408326705 4814943 29625295 269744131 4571378 2336746 87967 > 111289 210 > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs > 0 0 0 0 0 0 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 24235.85 11054.95 85 196 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 1339052 91 157160383 0 0 304 35176 2096917 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 1435270 95970 2852979 4376467 49452 > > Here is onstat -g seg from mid-day: > > Segment Summary: > id key addr size ovhd class blkused blkfree > 1 1381451777 30000000 534626304 9016 R 65256 6 > 2 1381451778 50000000 402653184 6740 V 24576 24576 > Total: - - 937279488 - - 89832 24582 > > (* segment locked in memory) > > From config file: > > BUFFERS 126000 # Maximum number of shared buffers > SHMVIRTSIZE 393216 # initial virtual shared memory segment> size > > I suppose we could reduce SHMVIRTSIZE (since we don't use what we > allocate) and > increase the BUFFERS to see if we can reduce the BTR? > > drbob