Informix allocating shared segments

Hi!, I'm having a problem with my informix server. It works great for 1-2 weeks and then start allocating new virtual shared memory segments and it never get them back. It happens until the swap is used complete and the server crash. I'm pretty sure it's some problem with my onconfig but I dont know where to start. It's not a too busy server, we have 6 concurrent sessions as maximum. online.log: 00:01:45 Dynamically allocated new virtual shared memory segment (size 200000KB) 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no SHMTOTAL limit Any idea? Thanks and Regards Emiliano Romero This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.

What version of the engine? I have seen memory leaks that can do this. Also what connections do you ahve after a week or two? onstat -u Declared Cursors? onstat -g stm Eric B. Rowell On Fri, Aug 15, 2008 at 11:26 AM, Emiliano Romero <eromero@sitrack.com>wrote: > Hi!, I'm having a problem with my informix server. It works great for > 1-2 weeks and then start allocating new virtual shared memory segments > and it never get them back. It happens until the swap is used complete > and the server crash. I'm pretty sure it's some problem with my onconfig > but I dont know where to start. It's not a too busy server, we have 6 > concurrent sessions as maximum. > > online.log: > > 00:01:45 Dynamically allocated new virtual shared memory segment (size > 200000KB) > 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no > SHMTOTAL limit> > Any idea? > > Thanks and Regards > > Emiliano Romero > > This email and any attachments thereof may contain confidential, > privileged, > proprietary, or otherwise private information. This email is intended > solely > for the use of the individual to whom it is addressed. If you are not the > intended recipient of the email and its attachments please inform the > sender > immediately and do not disclose the contents to any other person, use it > for > any purpose or store or copy the information in any way and delete this > e-mail > and its attachments from your system. Any views or opinions expressed are > solely those of the author. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Eric B. Rowell

You may need to configure a larger SHMVIRTSIZE. You can also use "onmode -F" to free up virtualsegments if they are not being used. You did not mention which platform you are on -- is it an AIX box ? Walt --- On Fri, 8/15/08, Emiliano Romero <eromero@sitrack.com> wrote: From: Emiliano Romero <eromero@sitrack.com> Subject: Informix allocating shared segments [13119] To: ids@iiug.org Date: Friday, August 15, 2008, 11:26 AM Hi!, I'm having a problem with my informix server. It works great for 1-2 weeks and then start allocating new virtual shared memory segments and it never get them back. It happens until the swap is used complete and the server crash. I'm pretty sure it's some problem with my onconfig but I dont know where to start. It's not a too busy server, we have 6 concurrent sessions as maximum. online.log: 00:01:45 Dynamically allocated new virtual shared memory segment (size 200000KB) 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no SHMTOTAL limit Any idea? Thanks and Regards Emiliano Romero This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

It does sound like it could be a server memory leak. What you would want to do is to start monitoring onstat -g mem and onstat -g seg output. In the onstat -g mem output you would want to do comparisons on pool sizes and look for any pool or pools that might be continually growing (so you'd want to keep some sort of history of -g mem output to do the comparisons to). The onstat -g seg would be incase you didn't see any pools getting larger in onstat -g mem output, but you did see fewer and fewer free blocks in the -g seg output.

Sorry for the low info provided. I use IBM Informix Dynamic Server Version 10.00.FC6 in a Linux box (Gentoo actually) I have 2 Gb of RAM. and SHMVIRTSIZE is set to 400000 (I try with 1000000 also but same result) And as I can see the server is eating 5.8GB of Memory (RAM+SWAP). onstat -u says: 37 active, 128 total, 49 maximum concurrent onstat -g stm just says: IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 7 days 21:29:11 -- 5884560 Kbytes I run onmode -F and online.log says: 17:11:48 Attempting to free unused operating system segments. This operation may take several minutes. But memory is still the same # onstat - IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 2 days 21:30:46 -- 5884560 Kbytes Regards Emiliano Romero Walter Lowich wrote: > You may need to configure a larger SHMVIRTSIZE. You can also use "onmode -F" > to free up virtualsegments if they are not being used. You did not mention > which platform you are on -- is it an AIX box ? > > Walt > > --- On Fri, 8/15/08, Emiliano Romero <eromero@sitrack.com> wrote: > > From: Emiliano Romero <eromero@sitrack.com> > Subject: Informix allocating shared segments [13119] > To: ids@iiug.org > Date: Friday, August 15, 2008, 11:26 AM > > Hi!, I'm having a problem with my informix server. It works great for > 1-2 weeks and then start allocating new virtual shared memory segments > and it never get them back. It happens until the swap is used complete > and the server crash. I'm pretty sure it's some problem with my > onconfig > but I dont know where to start. It's not a too busy server, we have 6 > concurrent sessions as maximum. > > online.log: > > 00:01:45 Dynamically allocated new virtual shared memory segment (size > 200000KB) > 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no > SHMTOTAL limit> > Any idea? > > Thanks and Regards > > Emiliano Romero > > This email and any attachments thereof may contain confidential, privileged, > proprietary, or otherwise private information. This email is intended solely > for the use of the individual to whom it is addressed. If you are not the > intended recipient of the email and its attachments please inform the sender > immediately and do not disclose the contents to any other person, use it for > any purpose or store or copy the information in any way and delete this e-mail > and its attachments from your system. Any views or opinions expressed are > solely those of the author. > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.

How about output from: onstat -g seg ipcs -m (as 'root') -- Bob -------------- Original message -------------- From: "Emiliano Romero" <eromero@sitrack.com> > Sorry for the low info provided. I use IBM Informix Dynamic Server > Version 10.00.FC6 in a Linux box (Gentoo actually) > I have 2 Gb of RAM. and SHMVIRTSIZE is set to 400000 (I try with 1000000 > also but same result) > > And as I can see the server is eating 5.8GB of Memory (RAM+SWAP). > > onstat -u says: 37 active, 128 total, 49 maximum concurrent > onstat -g stm just says: > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 7 > days 21:29:11 -- 5884560 Kbytes> > I run onmode -F and online.log says: 17:11:48 Attempting to free unused > operating system segments. This > operation may take several minutes. > But memory is still the same > # onstat -> > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 2 > days 21:30:46 -- 5884560 Kbytes> > Regards > > Emiliano Romero > > Walter Lowich wrote: > > You may need to configure a larger SHMVIRTSIZE. You can also use "onmode -F" > > to free up virtualsegments if they are not being used. You did not mention > > which platform you are on -- is it an AIX box ? > > > > Walt > > > > --- On Fri, 8/15/08, Emiliano Romero wrote: > > > > From: Emiliano Romero > > Subject: Informix allocating shared segments [13119] > > To: ids@iiug.org > > Date: Friday, August 15, 2008, 11:26 AM > > > > Hi!, I'm having a problem with my informix server. It works great for > > 1-2 weeks and then start allocating new virtual shared memory segments > > and it never get them back. It happens until the swap is used complete > > and the server crash. I'm pretty sure it's some problem with my > > onconfig > > but I dont know where to start. It's not a too busy server, we have 6 > > concurrent sessions as maximum. > > > > online.log: > > > > 00:01:45 Dynamically allocated new virtual shared memory segment (size > > 200000KB) > > 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no > > SHMTOTAL limit> > > > Any idea? > > > > Thanks and Regards > > > > Emiliano Romero > > > > This email and any attachments thereof may contain confidential, privileged, > > proprietary, or otherwise private information. This email is intended solely > > for the use of the individual to whom it is addressed. If you are not the > > intended recipient of the email and its attachments please inform the sender > > immediately and do not disclose the contents to any other person, use it for > > any purpose or store or copy the information in any way and delete this > e-mail > > and its attachments from your system. Any views or opinions expressed are > > solely those of the author. > > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Look at a onstat -g ses Look for session(s) that have a large amount of memory assigned. It could be a bad query. In the onstat -u Are there any with a very high number of rows read and written? If the "onmode -F" doesn't release anything then whenever is using memory should be active and in an "onstat -u". As for the Version... I have been told that FC6 was not a good version to be on. I would suggest you think about movig to FC8 as a general bug protection move (or FC9 when it is ready). But this is currently unrelated to this problem. Eric Rowell On Fri, Aug 15, 2008 at 1:11 PM, Emiliano Romero <eromero@sitrack.com>wrote: > Sorry for the low info provided. I use IBM Informix Dynamic Server > Version 10.00.FC6 in a Linux box (Gentoo actually) > I have 2 Gb of RAM. and SHMVIRTSIZE is set to 400000 (I try with 1000000 > also but same result) > > And as I can see the server is eating 5.8GB of Memory (RAM+SWAP). > > onstat -u says: 37 active, 128 total, 49 maximum concurrent > onstat -g stm just says: > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 7 > days 21:29:11 -- 5884560 Kbytes> > I run onmode -F and online.log says: 17:11:48 Attempting to free unused > operating system segments. This > operation may take several minutes. > But memory is still the same > # onstat -> > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 2 > days 21:30:46 -- 5884560 Kbytes> > Regards > > Emiliano Romero > > Walter Lowich wrote: > > You may need to configure a larger SHMVIRTSIZE. You can also use "onmode > -F" > > to free up virtualsegments if they are not being used. You did not > mention > > which platform you are on -- is it an AIX box ? > > > > Walt > > > > --- On Fri, 8/15/08, Emiliano Romero <eromero@sitrack.com> wrote: > > > > From: Emiliano Romero <eromero@sitrack.com> > > Subject: Informix allocating shared segments [13119] > > To: ids@iiug.org > > Date: Friday, August 15, 2008, 11:26 AM > > > > Hi!, I'm having a problem with my informix server. It works great for > > 1-2 weeks and then start allocating new virtual shared memory segments > > and it never get them back. It happens until the swap is used complete > > and the server crash. I'm pretty sure it's some problem with my > > onconfig > > but I dont know where to start. It's not a too busy server, we have 6 > > concurrent sessions as maximum. > > > > online.log: > > > > 00:01:45 Dynamically allocated new virtual shared memory segment (size > > 200000KB) > > 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no > > SHMTOTAL limit> > > > Any idea? > > > > Thanks and Regards > > > > Emiliano Romero > > > > This email and any attachments thereof may contain confidential, > privileged, > > proprietary, or otherwise private information. This email is intended > solely > > for the use of the individual to whom it is addressed. If you are not the > > intended recipient of the email and its attachments please inform the > sender > > immediately and do not disclose the contents to any other person, use it > for > > any purpose or store or copy the information in any way and delete this > e-mail > > and its attachments from your system. Any views or opinions expressed are > > solely those of the author. > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > This email and any attachments thereof may contain confidential, > privileged, > proprietary, or otherwise private information. This email is intended > solely > for the use of the individual to whom it is addressed. If you are not the > intended recipient of the email and its attachments please inform the > sender > immediately and do not disclose the contents to any other person, use it > for > any purpose or store or copy the information in any way and delete this > e-mail > and its attachments from your system. Any views or opinions expressed are > solely those of the author. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Eric B. Rowell

Thanks every one for your help. onstat -g sessession #RSAM total used dynamic id user tty pid hostname threads memory memory explain 52244 informix - 0 - 0 12288 11152 off 4 informix - 0 - 0 16384 12840 off 3 informix - 0 - 0 12288 11152 off 2 informix - 0 - 0 12288 11152 off onstat -uI put only the lines where I see read and Writes address flags sessid user tty wait tout locks nreads nwrites 86a1f028 ---P--D 1 root - 0 0 0 1729 10872 86a1f780 ---P--F 0 root - 0 0 0 0 878614 86a1fed8 ---P--F 0 root - 0 0 0 0 109421 86a20630 ---P--F 0 root - 0 0 0 0 200549 in onstat -g mem the bigger totalsize is name class addr totalsize freesize #allocfrag #freefrag res-buff0 R 4928a040 1024024576 4896 2 2 Blkpool Summary: name class addr size #blks mt V 8633a430 4452352 63 global V 86334ec0 0 0 onstat -g seg output:id key addr size ovhd class blkused blkfree 1802240 1381386241 44000000 1110589440 457824 R 271136 4 1835009 1381386242 86324000 409600000 13240 V 100000 0 1867779 1381386243 9e9c4000 204800000 6992 V 50000 0 1900548 1381386244 aad14000 204800000 6992 V 50000 0 1933317 1381386245 b7064000 204800000 6992 V 50000 0 1966086 1381386246 c33b4000 204800000 6992 V 50000 0 1998855 1381386247 cf704000 204800000 6992 V 50000 0 2031624 1381386248 dba54000 204800000 6992 V 50000 0 2064393 1381386249 e7da4000 204800000 6992 V 50000 0 2097162 1381386250 f40f4000 204800000 6992 V 50000 0 2129931 1381386251 100444000 204800000 6992 V 50000 0 2162700 1381386252 10c794000 204800000 6992 V 50000 0 2195469 1381386253 118ae4000 204800000 6992 V 50000 0 2228238 1381386254 124e34000 204800000 6992 V 50000 0 2261007 1381386255 131184000 204800000 6992 V 50000 0 2293776 1381386256 13d4d4000 204800000 6992 V 50000 0 2326545 1381386257 149824000 204800000 6992 V 50000 0 2359314 1381386258 155b74000 204800000 6992 V 50000 0 2392083 1381386259 161ec4000 204800000 6992 V 50000 0 2424852 1381386260 16e214000 204800000 6992 V 50000 0 2457621 1381386261 17a564000 204800000 6992 V 50000 0 2490390 1381386262 1868b4000 204800000 6992 V 50000 0 2523159 1381386263 192c04000 204800000 6992 V 50000 0 2555928 1381386264 19ef54000 204800000 6992 V 50000 0 2588697 1381386265 1ab2a4000 204800000 6992 V 26492 23508 Total: - - 6230589440 - - 1497628 23512 #ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x52564801 1802240 root 660 1110589440 28 0x52564802 1835009 root 660 409600000 28 0x7a038003 65538 zabbix 666 1099912 6 0x52564803 1867779 informix 660 204800000 28 0x52564804 1900548 informix 660 204800000 28 0x52564805 1933317 informix 660 204800000 28 0x52564806 1966086 informix 660 204800000 28 0x52564807 1998855 informix 660 204800000 28 0x52564808 2031624 informix 660 204800000 28 0x52564809 2064393 informix 660 204800000 28 0x5256480a 2097162 informix 660 204800000 28 0x5256480b 2129931 informix 660 204800000 28 0x5256480c 2162700 informix 660 204800000 28 0x5256480d 2195469 informix 660 204800000 28 0x5256480e 2228238 informix 660 204800000 28 0x5256480f 2261007 informix 660 204800000 28 0x52564810 2293776 informix 660 204800000 28 0x52564811 2326545 informix 660 204800000 28 0x52564812 2359314 informix 660 204800000 28 0x52564813 2392083 informix 660 204800000 28 0x52564814 2424852 informix 660 204800000 28 0x52564815 2457621 informix 660 204800000 28 0x52564816 2490390 informix 660 204800000 28 0x52564817 2523159 informix 660 204800000 28 0x52564818 2555928 informix 660 204800000 28 0x52564819 2588697 informix 660 204800000 28 I dont see any session using lot of memory. Informix is also working good now. Just I'll have to restart in 2-4 hours. I think I'm going to update to FC8. Thanks and Regards Emiliano Romero Eric Rowell wrote: > Look at a > > onstat -g ses> > Look for session(s) that have a large amount of memory > assigned. It could be a bad query. > > In the > > onstat -u> > Are there any with a very high number of rows read and written? > > If the "onmode -F" doesn't release anything then whenever is using > memory should be active and in an "onstat -u". > > As for the Version... I have been told that FC6 was not a good version to > be on. I would suggest you think about movig to FC8 as a general bug > protection move (or FC9 when it is ready). But this is currently unrelated > to this problem. > > Eric Rowell > On Fri, Aug 15, 2008 at 1:11 PM, Emiliano Romero <eromero@sitrack.com>wrote: > > >> Sorry for the low info provided. I use IBM Informix Dynamic Server >> Version 10.00.FC6 in a Linux box (Gentoo actually) >> I have 2 Gb of RAM. and SHMVIRTSIZE is set to 400000 (I try with 1000000 >> also but same result) >> >> And as I can see the server is eating 5.8GB of Memory (RAM+SWAP). >> >> onstat -u says: 37 active, 128 total, 49 maximum concurrent >> onstat -g stm just says: >> IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 7 >> days 21:29:11 -- 5884560 Kbytes>> >> I run onmode -F and online.log says: 17:11:48 Attempting to free unused >> operating system segments. This >> operation may take several minutes. >> But memory is still the same >> # onstat ->> >> IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 2 >> days 21:30:46 -- 5884560 Kbytes>> >> Regards >> >> Emiliano Romero >> >> Walter Lowich wrote: >> >>> You may need to configure a larger SHMVIRTSIZE. You can also use "onmode >>> >> -F" >> >>> to free up virtualsegments if they are not being used. You did not >>> >> mention >> >>> which platform you are on -- is it an AIX box ? >>> >>> Walt >>> >>> --- On Fri, 8/15/08, Emiliano Romero <eromero@sitrack.com> wrote: >>> >>> From: Emiliano Romero <eromero@sitrack.com> >>> Subject: Informix allocating shared segments [13119] >>> To: ids@iiug.org >>> Date: Friday, August 15, 2008, 11:26 AM >>> >>> Hi!, I'm having a problem with my informix server. It works great for >>> 1-2 weeks and then start allocating new virtual shared memory segments >>> and it never get them back. It happens until the swap is used complete >>> and the server crash. I'm pretty sure it's some problem with my >>> onconfig >>> but I dont know where to start. It's not a too busy server, we have 6 >>> concurrent sessions as maximum. >>> >>> online.log: >>> >>> 00:01:45 Dynamically allocated new virtual shared memory segment (size >>> 200000KB) >>> 00:01:45 Memory sizes:resident:1084560 KB, virtual:2200000 KB, no >>> SHMTOTAL limit>>> >>> Any idea? >>> >>> Thanks and Regards >>> >>> Emiliano Romero >>> >>> This email and any attachments thereof may contain confidential, >>> >> privileged, >> >>> proprietary, or otherwise private informat

Hmm, with this being 10.00.FC6 you could be running into a defect with the introduction of a new feature VP memory cacheing. You may want to try and add the following parameter into your onconfig file for the next time you bounce your server and see if the problem goes away. The parameter is VP_MEMORY_CACHE_KB, and you would want to set it to 0. Check this web page for more information: http://www-1.ibm.com/support/docview.wss?rs=630&context=SSGU8G&dc=D600&uid=swg21 255631&loc=en_US&cs=UTF-8&lang=en&rss=ct630db2

Ok, my server goes down due to swap going to limit. I have set VP_MEMORY_CACHE_KB to 0. Let's wait to see if it works. Thanks everyone for your help. Regards JACQUES RENAUT wrote: > Hmm, with this being 10.00.FC6 you could be running into a defect with the > introduction of a new feature VP memory cacheing. You may want to try and add > the following parameter into your onconfig file for the next time you bounce > your server and see if the problem goes away. The parameter is > VP_MEMORY_CACHE_KB, and you would want to set it to 0. > > Check this web page for more information: > > > http://www-1.ibm.com/support/docview.wss?rs=630&context=SSGU8G&dc=D600&uid=swg21 255631&loc=en_US&cs=UTF-8&lang=en&rss=ct630db2 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.

I've encountered this case before , but it's my program's bug , I run a endless loop esql/c program , which open a cursor without ever close and free the cursor , so the memory is running out of, and crash after hours !!!! Onstat -g seg will showes the session-id which cause problem , the " total memory" and "used memory" will be large !! and then onmode -z session-id to kill it , if you can not see such kind of session-id , it would be possible the memory leak of engine , and might need to upgrade engine ~~

Onstat -g seg will showes the session-id which cause problem , the " total memory" and "used memory" will be large !! and then onmode -z session-id to kill it , if you can not see such kind of session-id , it would be possible the memory leak of engine , and might need to upgrade engine ~~ Sorry .... it should be "onstat -g ses" , not "onstat -g seg" !!! My fault , mistyping ~~