Releasing memory

HP-UX 11i IDS 9.40.hc5 We had an issue here a week or so ago where our logical logs were filled up. Unfortunately, it happened on a weekend and no one caught the issue until the next Monday. That's straightened out. One of our apps decided that it wanted to open an enormous number of connections, seeing that certain things were failing, and caused the server to allocate an inordinate amount of memory. My question is this, short of bouncing the instance, is there a way to get Informix to release that memory? -- Chris Salch <ChrisSalch@letu.edu>

-----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Chris Salch Sent: Thursday, January 17, 2008 8:47 AM To: ids@iiug.org Subject: Releasing memory [10966] HP-UX 11i IDS 9.40.hc5 We had an issue here a week or so ago where our logical logs were filled up. Unfortunately, it happened on a weekend and no one caught the issue until the next Monday. That's straightened out. One of our apps decided that it wanted to open an enormous number of connections, seeing that certain things were failing, and caused the server to allocate an inordinate amount of memory. My question is this, short of bouncing the instance, is there a way to get Informix to release that memory? -- Chris Salch <ChrisSalch@letu.edu> ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. See you at the IIUG Informix 2008 Conference The Power Conference for Informix Professionals April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas http://www.iiug.org/conf Registration Now Open!! onmode -F - ScottM

Chris Salch wrote: > HP-UX 11i IDS 9.40.hc5 > > We had an issue here a week or so ago where our logical logs were filled > up. Unfortunately, it happened on a weekend and no one caught the issue > until the next Monday. That's straightened out. One of our apps > decided that it wanted to open an enormous number of connections, seeing > that certain things were failing, and caused the server to allocate an > inordinate amount of memory. > > My question is this, short of bouncing the instance, is there a way to > get Informix to release that memory? > If it hasn't been fragmented too badly onmode -F will free unused virtual segments back to the OS. Art S. Kagel Oninit ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Unfortunately, that seems to have had no effect. Would this represent fragemented memory? Segment Summary: id key addr size ovhd class blkused blkfree 1207 1381386242 80000000 201334784 6800 V 40200 8954 15815 1381386245 8c002000 33554432 1680 V 1171 7021 5608 1381386246 8e002000 33554432 1680 V 190 8002 8209 1381386247 90002000 33554432 1680 V 181 8011 6016 1381386248 92002000 33554432 1680 V 179 8013 12017 1381386249 94002000 33554432 1680 V 141 8051 26619 1381386251 96002000 33554432 1680 V 215 7977 20 1381386252 98002000 33554432 1680 V 204 7988 21 1381386253 9a002000 33554432 1680 V 176 8016 22 1381386254 9c002000 33554432 1680 V 186 8006 223 1381386255 9e002000 33554432 1680 V 171 8021 24 1381386256 a0002000 33554432 1680 V 120 8072 25 1381386257 a2002000 33554432 1680 V 160 8032 26 1381386258 a4002000 33554432 1680 V 122 8070 27 1381386259 a6002000 33554432 1680 V 195 7997 28 1381386260 a8002000 33554432 1680 V 158 8034 29 1381386261 aa002000 33554432 1680 V 133 8059 30 1381386262 ac002000 33554432 1680 V 248 7944 31 1381386263 ae002000 33554432 1680 V 123 8069 1006 1381386241 c508f000 587632640 239464 R* 143438 27 342218 1381386250 e9400000 33554432 1680 V 170 8022 2613 1381386243 ed629000 5406720 824 M 1291 29 14 1381386244 edb51000 5406720 824 M 1289 31 Total: - - 1437315072 - - 190461 160446 On Thu, 2008-01-17 at 10:55 -0500, Art S. Kagel (Oninit LLC) wrote: > Chris Salch wrote: > > HP-UX 11i IDS 9.40.hc5 > > > > We had an issue here a week or so ago where our logical logs were filled > > up. Unfortunately, it happened on a weekend and no one caught the issue > > until the next Monday. That's straightened out. One of our apps > > decided that it wanted to open an enormous number of connections, seeing > > that certain things were failing, and caused the server to allocate an > > inordinate amount of memory. > > > > My question is this, short of bouncing the instance, is there a way to > > get Informix to release that memory? > > > If it hasn't been fragmented too badly onmode -F will free unused > virtual segments back to the OS. > > Art S. Kagel > Oninit > > > ================================================================================ =========== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > > ================================================================================ =========== > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! -- -------------------------------------------- Chris Salch Programmer/Analyst LeTourneau University 903-233-3537

Scott, I have been away from Informix for a bit but we used to run a onstat -F in cron each morning to free memory. (Embedded image moved to file: pic24389.jpg) "Scott Mackenzie" <scottm@dinecolle ge.edu> To Sent by: ids@iiug.org ids-bounces@iiug. cc org Subject RE: Releasing memory [10967] 01/17/2008 10:51 AM Please respond to ids@iiug.org -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Chris Salch Sent: Thursday, January 17, 2008 8:47 AM To: ids@iiug.org Subject: Releasing memory [10966] HP-UX 11i IDS 9.40.hc5 We had an issue here a week or so ago where our logical logs were filled up. Unfortunately, it happened on a weekend and no one caught the issue until the next Monday. That's straightened out. One of our apps decided that it wanted to open an enormous number of connections, seeing that certain things were failing, and caused the server to allocate an inordinate amount of memory. My question is this, short of bouncing the instance, is there a way to get Informix to release that memory? -- Chris Salch <ChrisSalch@letu.edu> ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. See you at the IIUG Informix 2008 Conference The Power Conference for Informix Professionals April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas http://www.iiug.org/conf Registration Now Open!! onmode -F - ScottM ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. See you at the IIUG Informix 2008 Conference The Power Conference for Informix Professionals April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas http://www.iiug.org/conf Registration Now Open!!

Yes, if those are all informix segments, you have a lot of fragmented memory. You may need to bounce your informix engine (stop/start) to clean it up. the pros out here will likely post excellent advise on resizing your SHMVIRTSIZE and SHMADD in onconfig to be more efficient. When you do "onstat -g seg" and you see a a lot of class "V" segments, your engine has requested a lot of additional memory over time. If onmode -F does not free you, you would need to bounce engine to fix, after you resize SHMVIRTSIZE and SHMADD in your onconfig. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Chris Salch Sent: Thursday, January 17, 2008 10:04 AM To: ids@iiug.org Subject: Re: Releasing memory [10969] Unfortunately, that seems to have had no effect. Would this represent fragemented memory? Segment Summary: id key addr size ovhd class blkused blkfree 1207 1381386242 80000000 201334784 6800 V 40200 8954 15815 1381386245 8c002000 33554432 1680 V 1171 7021 5608 1381386246 8e002000 33554432 1680 V 190 8002 8209 1381386247 90002000 33554432 1680 V 181 8011 6016 1381386248 92002000 33554432 1680 V 179 8013 12017 1381386249 94002000 33554432 1680 V 141 8051 26619 1381386251 96002000 33554432 1680 V 215 7977 20 1381386252 98002000 33554432 1680 V 204 7988 21 1381386253 9a002000 33554432 1680 V 176 8016 22 1381386254 9c002000 33554432 1680 V 186 8006 223 1381386255 9e002000 33554432 1680 V 171 8021 24 1381386256 a0002000 33554432 1680 V 120 8072 25 1381386257 a2002000 33554432 1680 V 160 8032 26 1381386258 a4002000 33554432 1680 V 122 8070 27 1381386259 a6002000 33554432 1680 V 195 7997 28 1381386260 a8002000 33554432 1680 V 158 8034 29 1381386261 aa002000 33554432 1680 V 133 8059 30 1381386262 ac002000 33554432 1680 V 248 7944 31 1381386263 ae002000 33554432 1680 V 123 8069 1006 1381386241 c508f000 587632640 239464 R* 143438 27 342218 1381386250 e9400000 33554432 1680 V 170 8022 2613 1381386243 ed629000 5406720 824 M 1291 29 14 1381386244 edb51000 5406720 824 M 1289 31 Total: - - 1437315072 - - 190461 160446 On Thu, 2008-01-17 at 10:55 -0500, Art S. Kagel (Oninit LLC) wrote: > Chris Salch wrote: > > HP-UX 11i IDS 9.40.hc5 > > > > We had an issue here a week or so ago where our logical logs were filled > > up. Unfortunately, it happened on a weekend and no one caught the issue > > until the next Monday. That's straightened out. One of our apps > > decided that it wanted to open an enormous number of connections, seeing > > that certain things were failing, and caused the server to allocate an > > inordinate amount of memory. > > > > My question is this, short of bouncing the instance, is there a way to > > get Informix to release that memory? > > > If it hasn't been fragmented too badly onmode -F will free unused > virtual segments back to the OS. > > Art S. Kagel > Oninit > > > ======================================================================== =================== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > > ======================================================================== =================== > > > ************************************************************************ ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! -- -------------------------------------------- Chris Salch Programmer/Analyst LeTourneau University 903-233-3537 ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. See you at the IIUG Informix 2008 Conference The Power Conference for Informix Professionals April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas http://www.iiug.org/conf Registration Now Open!! ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Chris Salch wrote: > Unfortunately, that seems to have had no effect. Would this represent > fragemented memory? > > Segment Summary: > id key addr size ovhd class blkused blkfree > 1207 1381386242 80000000 201334784 6800 V 40200 8954 > 15815 1381386245 8c002000 33554432 1680 V 1171 7021 > 5608 1381386246 8e002000 33554432 1680 V 190 8002 > 8209 1381386247 90002000 33554432 1680 V 181 8011 > 6016 1381386248 92002000 33554432 1680 V 179 8013 > 12017 1381386249 94002000 33554432 1680 V 141 8051 > 26619 1381386251 96002000 33554432 1680 V 215 7977 > 20 1381386252 98002000 33554432 1680 V 204 7988 > 21 1381386253 9a002000 33554432 1680 V 176 8016 > 22 1381386254 9c002000 33554432 1680 V 186 8006 > 223 1381386255 9e002000 33554432 1680 V 171 8021 > 24 1381386256 a0002000 33554432 1680 V 120 8072 > 25 1381386257 a2002000 33554432 1680 V 160 8032 > 26 1381386258 a4002000 33554432 1680 V 122 8070 > 27 1381386259 a6002000 33554432 1680 V 195 7997 > 28 1381386260 a8002000 33554432 1680 V 158 8034 > 29 1381386261 aa002000 33554432 1680 V 133 8059 > 30 1381386262 ac002000 33554432 1680 V 248 7944 > 31 1381386263 ae002000 33554432 1680 V 123 8069 > 1006 1381386241 c508f000 587632640 239464 R* 143438 27 > 342218 1381386250 e9400000 33554432 1680 V 170 8022 > 2613 1381386243 ed629000 5406720 824 M 1291 29 > 14 1381386244 edb51000 5406720 824 M 1289 31 > Total: - - 1437315072 - - 190461 160446 > Yes, unfortunately a small part of each virtual segment (120-204 pages each) is being used, so the segment can't be freed. As sessions drop away, you may be able to free up the segment that each session had been using. The only other solution would be to bring the engine offline and back up to free the memory. Unless this is unusual it may be a sign that you need to increase the initial virtual segment from where it is (200MB?) to include the 19 33MB additional memory segments bringing the total up to about 800MB. But given that the segments are only about 3% used, I don't think that's needed. Art S. Kagel Oninit ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Yes, this was a very unusual situation. Thanks all. On Thu, 2008-01-17 at 12:01 -0500, Art S. Kagel (Oninit LLC) wrote: > Chris Salch wrote: > > Unfortunately, that seems to have had no effect. Would this represent > > fragemented memory? > > > > Segment Summary: > > id key addr size ovhd class blkused blkfree > > 1207 1381386242 80000000 201334784 6800 V 40200 8954 > > 15815 1381386245 8c002000 33554432 1680 V 1171 7021 > > 5608 1381386246 8e002000 33554432 1680 V 190 8002 > > 8209 1381386247 90002000 33554432 1680 V 181 8011 > > 6016 1381386248 92002000 33554432 1680 V 179 8013 > > 12017 1381386249 94002000 33554432 1680 V 141 8051 > > 26619 1381386251 96002000 33554432 1680 V 215 7977 > > 20 1381386252 98002000 33554432 1680 V 204 7988 > > 21 1381386253 9a002000 33554432 1680 V 176 8016 > > 22 1381386254 9c002000 33554432 1680 V 186 8006 > > 223 1381386255 9e002000 33554432 1680 V 171 8021 > > 24 1381386256 a0002000 33554432 1680 V 120 8072 > > 25 1381386257 a2002000 33554432 1680 V 160 8032 > > 26 1381386258 a4002000 33554432 1680 V 122 8070 > > 27 1381386259 a6002000 33554432 1680 V 195 7997 > > 28 1381386260 a8002000 33554432 1680 V 158 8034 > > 29 1381386261 aa002000 33554432 1680 V 133 8059 > > 30 1381386262 ac002000 33554432 1680 V 248 7944 > > 31 1381386263 ae002000 33554432 1680 V 123 8069 > > 1006 1381386241 c508f000 587632640 239464 R* 143438 27 > > 342218 1381386250 e9400000 33554432 1680 V 170 8022 > > 2613 1381386243 ed629000 5406720 824 M 1291 29 > > 14 1381386244 edb51000 5406720 824 M 1289 31 > > Total: - - 1437315072 - - 190461 160446 > > > Yes, unfortunately a small part of each virtual segment (120-204 pages > each) is being used, so the segment can't be freed. As sessions drop > away, you may be able to free up the segment that each session had been > using. The only other solution would be to bring the engine offline and > back up to free the memory. Unless this is unusual it may be a sign > that you need to increase the initial virtual segment from where it is > (200MB?) to include the 19 33MB additional memory segments bringing the > total up to about 800MB. But given that the segments are only about 3% > used, I don't think that's needed. > > Art S. Kagel > Oninit > > > ================================================================================ =========== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > > ================================================================================ =========== > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! -- Chris Salch <ChrisSalch@letu.edu>