RE: Btree Percentage

Does the engine need to be recycled? -----Original Message----- From: hanna_shaw@my-deja.com [mailto:hanna_shaw@my-deja.com] Sent: Tuesday, December 12, 2000 11:24 AM To: informix-list@iiug.org Subject: Re: Btree Percentage Hi, Frank, Thanks for your help. It's new for me. I never heard LRUAGE before. I tried it in our production box. But I didn't see any changes in the box. I think I did everything as you said. First, I went to $INFORMIXDIR/bin, did 'strings oninit|grep LRUAGE', and I got a line which means it's supported in the platform. Then I did 'export LRUAGE=1' in UNIX.(I typed 'env|grep LRUAGE' to verify that it's set correctly.) Then I typed 'onstat -R'. Here is the tail output: ... 252 f 2485 99.3% 2467 0 14 2248 205 253 m 0.7% 18 0 18 0 0 254 f 2504 99.5% 2491 0 30 2236 225 255 m 0.5% 13 0 13 0 0 1765 dirty, 319173 queued, 320000 total, 524288 hash buckets, 2048 buffer size start clean at 2% (of pair total) dirty, or 50 buffs dirty, stop at 1% 0 priority downgrades, 0 priority upgrades As you said, 'priority downgrades' should be some number greater than zero. But it's still zero. Do you know if I did anything not correct? Btw, our Informix version is 7.31.uc4. OS is Solaris 2.6. Thanks In article <3A354278.A47C8B93@lafr.de>, Frank Langelage <frank@lafr.de> wrote: > hanna_shaw@my-deja.com schrieb: > > > > Hi, > > > > We have a performance problem in one of our production box for a long > > time. I found the percentage of Btree in the box is really high. Here > > is the tail part of output of 'onstat -P': > > > > Percentages: > > Data 3.38 > > Btree 95.41 > > Other 1.21 > > > > Output of 'onstat -R': > > ... > > # f/m pair total % of length LOW MED_LOW MED_HIGH HIGH > > 0 f 2477 98.7% 2446 0 229 2010 207 > > 1 m 1.3% 31 0 31 0 0 > > 2 f 2476 98.9% 2450 0 240 2010 200 > > 3 m 1.1% 26 0 26 0 0 > > ... > > > > Most are 'MED_HIGH' instead of 'MED_LOW'. I checked the previous > > related emails in the news group and found some suggestion for this > > problem. But none seems to be a solution of our problem. Our current > > Informix version is 7.31.uc4. 'NOAGE' is already set to 1. > > > > I also found that the performance is pretty good everytime when we > > recycle the Informix server. And then it will be worse and worse until > > we recycle it again.(Now we recycle it once a week. We can't recycle it > > everyday.) We had a batch job running every night. After recycle, it > > just takes minutes. But before recycle, it even couldn't finish in 24 > > hours and blocks all other jobs. > > > > Does anyone know how to solve the performance problem? > > > > Thanks in advance. > > I got the same problem after upgrade from 7.30.UC2 to 7.31.UC6 on SCO > UnixWare 7.1.1. > There are two recommended Environmentvariables (Shell-Variables) > NOLRUPRIO and LRUAGE. > My experience is, that setting LRUAGE=1 and not setting NOLRUPRIO gets > the best result. > But LRUAGE is supported only in newer releases. > You can check this like this: > - go to $INFORMIXDIR > - do strings bin/oninit | grep LRUAGE > If you get a result, the server knows about the variable. > Then add LRUAGE=1; export LRUAGE to your profile (/etc/profile or > .profile of user who starts the IDS-Server). > > If it is working, you will see a value greater than zero on the last > line of onstat -R for "priority downgrades". > > Regards > Frank > Sent via Deja.com http://www.deja.com/ Before you buy.