onstat -g seg reveals several virtual segments many show a pool summary of 17184.H.sd

This system is running one 14.10.FC11X8 standard server with two RSS servers. For some time onstat -g seg shows an increasing number of virtual segments - we have an alert for a threshold of 10 or more: IBM Informix Dynamic Server Version 14.10.FC11X8AEE -- On-Line -- Up 5 days 23:31:27 -- 17285492 Kbytes 2026-07-15 09:01:45Segment Summary: id key addr size ovhd class blkused blkfree 21 52594801 44000000 16650240 636472 R 4065 0 22 52594802 44fe1000 4096000000 48001848 V 799996 200004 23 52594803 139221000 1018445824 1 B 248644 0 24 52594804 175d65000 9762045952 1 B 2383312 0 25 52594805 3bbb35000 83361792 1 B 20352 0 26 52594806 3c0ab5000 262144000 3073656 V 64000 0 27 52594807 3d04b5000 262144000 3073656 V 64000 0 28 52594808 3dfeb5000 262144000 3073656 V 64000 0 29 52594809 3ef8b5000 262144000 3073656 V 64000 0 30 5259480a 3ff2b5000 262144000 3073656 V 63998 2 31 5259480b 40ecb5000 102400000 1201608 VX 316 24684 32 5259480c 414e5d000 262144000 3073656 V 32183 31817 33 5259480d 42485d000 262144000 3073656 V 6038 57962 34 5259480e 43425d000 262144000 3073656 V 4290 59710 35 5259480f 443c5d000 262144000 3073656 V 1497 62503 36 52594810 45365d000 262144000 3073656 V 786 63214 Total: - - 17700343808 - - 3821477 499896 (* segment locked in memory) Virtual segment low memory reserve (bytes):819200000 Low memory reserve used 0 times and used maximum block size 0 bytes We have set the Low Memory reserve to stop OOM Killer doing its thing. Exploring onstat -g mem reveals a few hundred of these: IBM Informix Dynamic Server Version 14.10.FC11X8AEE -- On-Line -- Up 5 days 23:32:30 -- 17285492 Kbytes 2026-07-15 09:02:48Pool Summary: name class addr totalsize freesize #allocfrag #freefrag aqtpool V 497c5040 8192 1104 6 2 SES.356.452 V b2b62040 4096 160 2 1 17184.H.sd V d1bae040 8192 408 15 2 17184.H.sd V a9db1040 12288 2008 29 1 17184.H.sd V c0c4a040 12288 3728 22 1 17184.H.sd V d45c1040 20480 1424 39 2 17184.H.sd V d39fd040 24576 1488 43 2 17184.H.sd V 3c5372040 12288 3728 22 1 17184.H.sd V 3c26f7040 12288 368 46 1 17184.H.sd V 3c8c96040 32768 4232 57 3 17184.H.sd V 3cd392040 12288 3728 22 1 17184.H.sd V 3cd436040 12288 3728 22 1 17184.H.sd V 3cf2fe040 12288 3728 22 1 17184.H.sd V 3c39ee040 12288 656 42 1 17184.H.sd V 3ced6f040 12288 3728 22 1 17184.H.sd V 3c7e59040 12288 2224 34 1 17184.H.sd V 3cc932040 12288 2968 26 1 17184.H.sd V 3c9410040 12288 3136 26 1 17193.H.sd V 3c130a040 8192 408 15 2 17193.H.sd V 3c68ce040 12288 3728 22 1 Where do I start digging? It's a 64Gb box and increasing SHMVRTSIZE to 20Gb is just delaying the inevitable. ------------------------------ Stuart Stephens ------------------------------

Hello Do you have by chance RALLOC_MODE POOL in the onconfig? This setting changes the allocation of shared memory pools What means you will see additional pools. Normally such memory is allocated in other pools (e.g session pool) So can be that this is high number is not pointing to an issue. In the onstat -g seg I see Segment Summary: id key addr size ovhd class blkused blkfree 32 5259480c 414e5d000 262144000 3073656 V 32183 31817 33 5259480d 42485d000 262144000 3073656 V 6038 57962 I mean there are additional shared memory segments but at the time of collecting the onstat, most blocks unused. What looks like situation with high memory usage is already over. Which then is not giving a hint about what has needed the additional shared memory segment. You need to monitor onstat -g seg/onstat -g mem to see what is allocated when the need for additional shared memory starts and is ongoing. Then you can check what is run in the session(s). (the number in the pool name is the session id) ------------------------------ Hedwig Fuchs ------------------------------

Stuart: What do you have VP_MEMORY_CACHE_KB set to? Also, does "onmode -F" remove the unused segments? Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Hi Art What do you have VP_MEMORY_CACHE_KB set to? Set to 0 Also, does "onmode -F" remove the unused segments? No In response to Hedwig's observation, should we be removing " RALLOC_MODE POOL"? Customer Services Director Monitor Computer Systems 4 Cayley Court George Cayley Court York YO30 4WH Main: 01904 948670 DDI: 01904 949988 Email: stuart.stephens@monitor.uk

Hello removing RALLOC_MODE POOL will not change to overall need for memory. It will only generate less pools. A shorter onstat -g mem can be better to identify pools which are growing when "allocating additional shared memory segments" is ongoing, Support can help here. But support needs a case. ------------------------------ Hedwig Fuchs ------------------------------

Stuart: Yes, RALLOC_MODE is a diagnostic setting only used temporarily on advice from tech support to help them diagnose specific suspected memory issues. It has been known to cause memory allocation issues of its own in the past. You should unset that. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Will do thank you - I will monitor over the next few days. Would you recommend setting VP_MEMORY_CACHE_KB? Customer Services Director Monitor Computer Systems 4 Cayley Court George Cayley Court York YO30 4WH Main: 01904 948670 DDI: 01904 949988 Email: stuart.stephens@monitor.uk

Stuart: For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset. For reference, I set my server to: VP_MEMORY_CACHE_KB 4096,STATICand use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments. (Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.) Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Thanks Art Customer Services Director Monitor Computer Systems 4 Cayley Court George Cayley Court York YO30 4WH Main: 01904 948670 DDI: 01904 949988 Email: stuart.stephens@monitor.uk

I agree with Art although I tend to use 8K Paul Watson www.oninit.com Tel: +1 913 387 7529

Since removing RALLOC_MODE POOL No memory growth has been observed Customer Services Director Monitor Computer Systems 4 Cayley Court George Cayley Court York YO30 4WH Main: 01904 948670 DDI: 01904 949988 Email: stuart.stephens@monitor.uk

Hi Stuart, Glad to see that the problem was resolved. During investigations of memory issues, Informix support will often request that RALLOC_MODE be set to POOL. While there might be a slight increase in memory usage we have not seen this result in many new segments to be added. Do you remember when RALLOC_MODE POOL was set within the onconfig file? ------------------------------ ROBERT JANE ------------------------------

That will have been done in November 2024 when I upgraded them from 14.10.FC10 to 14.10.FC11X8 Customer Services Director Monitor Computer Systems 4 Cayley Court George Cayley Court York YO30 4WH Main: 01904 948670 DDI: 01904 949988 Email: stuart.stephens@monitor.uk

Hi Stuart, If it has been set to POOOL for that long and this type of behavior has not seen before then the changing of this to HEAP and bouncing the engine was probably coincidental. Looking at some of the onstat snippets posted above then I have a feeling that a session or maybe some sessions were performing work which resulted in odd behavior to be seen with the memory allocation & freeing so that the (last) position inside the segment advanced through the virtual segments leaving big memory gaps and when the advancement reached the end of the segment, the engine had to allocate a new segment even though there was a lot of free space in the current segment. I hope not but if you experience this type of behavior again then would it be possible to collect ... onstat -o onstat -afive onstat -g seg, mem & nbm taken about one minute apart. ------------------------------ ROBERT JANE ------------------------------