btree invalidation

I have the following line in the output of onstat -g mem btree inval V c000000054330028 1745338368 149991704 1704431 213054 I'm care about that because the last week the number of memory segments (onstat -g seg) has increased and onmode -F has no efect. I've noticed that "btree inval" is 1745338368 (that means aprox. 1.6 GB of virtual memory) What means "btree inval " and how can I do to release this memory ? Thanks in advance Peter

On 22 Dec, 21:05, roger_vi...@yahoo.es wrote: > I have the following line in the output of onstat -g mem > > btree inval  V     c000000054330028 1745338368 149991704 1704431 > 213054 > > I'm care about that because the last week the number of memory > segments (onstat -g seg) has increased and onmode -F has no efect. > > I've noticed that "btree inval" is 1745338368 (that means aprox. 1.6 > GB of virtual memory) > What means "btree inval " and how can I do to release this memory ? > > Thanks in advance > > Peter Which Informix version? What does onstat -C show the btree scanners are doing? What does onstat -g stk all and onstat -g sql all show? Are online index rebuilds in progress?

My version is: Informix Dynamic Server Version 7.31.FD3W1 There is no Index rebuild A typícal output of onstat -C is: Btree Cleaner Info btcleanr pool flags pools npend busypnum head tail free c000000052ab6ab8 c0000000fa7b6ec0 1 5 8 0 c0000000fa7b6ec0 c00000006583f3c8 c00000006a602fb0 nreqs dups success dfrmv unnec ditems ditlks cmprs palcs 21223 0 21484 21484 99 94234 1435733 361 0 outstanding requests address next partnum pagenum keynum sequence c0000000fa7b6ec0 c0000000fa7b6ee0 f00085 5 c0000000544d3f58 102831764 c0000000fa7b6ee0 c0000000fa7b6f00 f00085 1a c0000000544d3f98 102831764 c0000000f73ffac8 c0000000f73ffae8 1300007 1 c000000054748a70 102831767 c0000000f73ffae8 c0000000f73ffb08 1300007 2 c000000054748ab8 102831767 c0000000fb762260 c0000000fb762280 1e0000a 3bb33 c000000054755dd0 102831769 c00000006ccf3890 c00000006ccf38b0 1300006 1 c00000005bb7fdc0 102831786 c00000006ccf38b0 c00000006ccf38d0 1300006 2 c00000005bb7fe08 102831786 c00000006583f1e8 c00000006583f208 1300003 8fc91 c000000054733b98 102831788 Invalidation Requests count sequence special 28539542 102831789 28487087

Btree invalidation is typical of the btree CLEANER thread which is the old technology that was replaced by the btree scanner (In 7.31.xC8 if I am not mistaken). The invalidation request is the list of all cleaning requests that have been invalidated. All requests younger than the oldest transaction open in the system need to be kept in this list. So if you have a very large logical log (enough to not to generate a long TX) and have a lot of activity and a very old open transaction this list could grown very large. Your options are to open a PMR with tech support to discard a memory leak or and/or upgrade to the latest version of 7.31 of the btree scanner. IN that sense and since the end of life of 7.31 is very close you should start testing 10.00.xC9 or newer to migrate. One of the things that you will likely want to do running the btree scanner in 10 is to DETACH all indexes in the bigger tables with more than one index as this will allow the usage of the more efficient RANGE and ALICE operational modes. regards gustavo roger_vilca@yahoo.es wrote: > My version is: Informix Dynamic Server Version 7.31.FD3W1 > There is no Index rebuild > > A typícal output of onstat -C is: > > Btree Cleaner Info > btcleanr pool flags pools npend busypnum > head tail free > c000000052ab6ab8 c0000000fa7b6ec0 1 5 8 0 > c0000000fa7b6ec0 c00000006583f3c8 c00000006a602fb0 > > nreqs dups success dfrmv unnec ditems ditlks cmprs > palcs > 21223 0 21484 21484 99 94234 1435733 361 0 > > outstanding requests > address next partnum pagenum keynum sequence > c0000000fa7b6ec0 c0000000fa7b6ee0 f00085 5 c0000000544d3f58 > 102831764 > c0000000fa7b6ee0 c0000000fa7b6f00 f00085 1a c0000000544d3f98 > 102831764 > c0000000f73ffac8 c0000000f73ffae8 1300007 1 c000000054748a70 > 102831767 > c0000000f73ffae8 c0000000f73ffb08 1300007 2 c000000054748ab8 > 102831767 > c0000000fb762260 c0000000fb762280 1e0000a 3bb33 c000000054755dd0 > 102831769 > c00000006ccf3890 c00000006ccf38b0 1300006 1 c00000005bb7fdc0 > 102831786 > c00000006ccf38b0 c00000006ccf38d0 1300006 2 c00000005bb7fe08 > 102831786 > c00000006583f1e8 c00000006583f208 1300003 8fc91 c000000054733b98 > 102831788 > > Invalidation Requests > count sequence special > 28539542 102831789 28487087 > > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > >

The CLEANERS parameter is set to 120 in the onconfig file. I believe that this is the maximum. I have a few doubts about the way how it works: When a cleaning request is invalidated ?, why ? When you indicate "All requests younger...", do you refer to cleaning requests ? Thanks for your response. best regards