Using onstat -m -r Issue

I'd like to inquire whether anyone has experienced memory issues when using the repeat option of the onstat -m command (onstat -m -r) ? We are running IDS 10.0 on Solaris 10 and there have been several occasions where one of our instances would not come up when being restarted due to an out of memory error in the resident portion. shmat: [ENOMEM][12]: out of available data space, check system memory parameters (e.g. MAXMEM). mt_shm_init: can't create resident segment. In this exampe, when our instances are up, there is always plenty of memory free, so we looked for some other process using memory at the time. We tracked it down to an onstat –m –r running. Apparently, the utility attaches to the shared memory location and when the instance is brought down, the memory is not totally released since a process is running against it. Once the onstat is canceled, the memory is released and the instance can be started successfully. We wanted to further investigate whether this is a bug or just the way it works (i.e. bringing down the instance would not necessarily kill your onstat process, so you must remember to cancel it). We tried researching known issues for subject, but find none, so just curious. Thanks

Hi, the server instance is comprised of relatively few running processes of the "oninit" binary. These processes are "tightly coupled" as they communicate frequently with each other. They also create the shared memory segments used by the instance. The "onstat" utility attaches to the server instances shared memory, but that happens without the oninit processes really knowing about it. The "onstat" process reads the shared memory in a "dirty read" fashion (i.e. without synchronising with the oninit processes; that's why very occasionally "onstat" can receive a "changing data structure" error ...). [ In that way "onstat" is different from the "onmode" utility, which communicates actively with the server. In the server there's a corresponding thread "onmode_mon". ] In addition to this come the facts that I recently explained in an e-mail to this forum/newsgroup ... for details try to find it by looking for my name ... In short: Many OSs these days do not allow removal of SHM segments as long as some process is attached to it ("onstat" in your case). Even "ipcrm -m <shm ID>" executed as user root will not do it. You have to actively find the processes and terminate them. After that the SHM segments will be removed (and the memory will be available again). I remember that this used to be different in (some) older OS versions. Conclusion: Yes, what you see is expected, it is not a bug/defect. You need to find and kill such running onstat processes. The same is true for stray dbaccess connected via SHM ... Alternatively (at least on UNIX/Linux) you could use "tail -f <message file>" to achieve what the "onstat -m -r" does. This does not use SHM, is much less resource intensive, gives a much better output (because lines are not repeated), and it will work even across server shutdown and startup (i.e. no need to kill and restart the "tail"). I always use "tail -f ...". It never occured to me to do "onstat -m -r" ... :) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 ids-bounces@iiug.org wrote on 01.06.2007 01:24:58: > I'd like to inquire whether anyone has experienced memory issues when using > the repeat option of the onstat -m command (onstat -m -r) ? > > We are running IDS 10.0 on Solaris 10 and there have been several occasions > where one of our instances would not come up when being restarted due to an > out of memory error in the resident portion. > > shmat: [ENOMEM][12]: out of available data space, check system memory > parameters (e.g. MAXMEM). > mt_shm_init: can't create resident segment. > > In this exampe, when our instances are up, there is always plenty of memory > free, so we looked for some other process using memory at the time. We tracked > it down to an onstat ?m ?r running. Apparently, the utility attaches to the > shared memory location and when the instance is brought down, the memory is > not totally released since a process is running against it. Once the onstat is > canceled, the memory is released and the instance can be started successfully. > > We wanted to further investigate whether this is a bug or just the way it > works (i.e. bringing down the instance would not necessarily kill your onstat> process, so you must remember to cancel it). > > We tried researching known issues for subject, but find none, so just curious. > > Thanks > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum.