Btree Percentage

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. Sent via Deja.com http://www.deja.com/ Before you buy.

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

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.

You have to bounce the engine. -- Jay Aymond Community Coffee <hanna_shaw@my-deja.com> wrote in message news:915jdq$jhj$1@nnrp1.deja.com... > 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.

hanna_shaw@my-deja.com wrote in <9137e6$n97$1@nnrp1.deja.com>: >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': You didn't mention what OS you were using. There is a chance the OS itself does not support NOAGE, or the port of Informix to that version of that OS might not. -- William Harris william@carsinfo.com

Solaris 2.6. I think NOAGE is supported in the OS. Here is the part in the document IDS_7.3 at $INFORMIXDIR/release/en_us/0333: 11. The no aging feature that disables priority aging of CPU virtual processors by the operating system is supported on this port. This feature can be activated through the onconfig parameter NOAGE. So I think there is no problem with NOAGE. But it seems no use at all... In article <915pfv$fnk$1@malgudi.oar.net>, william@carsinfo.com (William Harris) wrote: > hanna_shaw@my-deja.com wrote in <9137e6$n97$1@nnrp1.deja.com>: > >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': > > You didn't mention what OS you were using. There is a chance the OS itself > does not support NOAGE, or the port of Informix to that version of that OS > might not. > -- > William Harris william@carsinfo.com > Sent via Deja.com http://www.deja.com/

Jay Aymond schrieb: > > You have to bounce the engine. > > -- This is really necessary !!! After setting LRUAGE to 1 you have to stop and restart then engine from this shell. The environment variable is only read at startup. Regards Frank