Re: Dynamically adding shared memory segs

Martin Berns wrote: > > Mark D. Stock schrieb: > > > > Martin Berns wrote: > > > > > > Bill Weaver schrieb: > > > > > > > > Today for some reason we've added 5 shared memory segments dynamically. It almost never happens > > > > that we even have 1 added since I've worked to size our initial segment to avoid this. How can > > > > I tell what is causing us to add so many all of a sudden? > > > [snip] > > > > > > Run 'onstat -g ses' and have a look at the 'total memory' column. This may indicate who is using > > > the additional memory. Remember, sessions don't free memory by themselves: So if there is a big > > > difference between 'total memory' and 'used memory' you should think about running 'onmode -F' > > > every x minutes/hours by cron. > > > > Don't do that! > > > > If you have a one-off allocation of virtual segments, then free them > > with a one-off onmode -F. > > > > If you have regular allocation of virtual segments, then tune the > > SHMVIRTSIZE & SHMADD parameters.> > > Hi Mark, > can you tell us why not to do that by cron? > I can understand that the engine isn't doing this itself. But if I can't get > more physical memory, i would prefer to do some cronjobs instead of paging! The actual allocation of memory segments is an overhead in terms of performance. That is BEFORE you get into the platform specific problems with multiple SHM segments. If the segments were allocated for a one-off operation, such as creating an index, then a one-off deallocation will suffice. If the segments are continuously being allocated, then the SHMVIRTSIZE & SHMADD parameters are not tuned correctly. By deallocating all unused segments via a cron job, you are counteracting the work done by the engine in allocating them, because it will have to re-allocate them when it needs the space. If you are paging, then either your SHMVIRTSIZE & SHMADD parameters are not tuned correctly, or your machine does not have enough memory. Again, if the segments were allocated for a one-off operation, such as creating an index, then the DBA, or whoever monitors IDS activity, should do a one-off deallocation. It was probably the same person that caused the allocation anyway. ;-) Cheers, -- Mark. +----------------------------------------------------------+-----------+ |Mark D. Stock - Informix SA http://www.informix.com |//////// /| |mailto:mdstock@informix.com http://www.informix.com/idn |///// / //| |http://www.iiug.org +-----------------------------------+//// / ///| | Tel: +27 11 807 0313 |If it's slow, the users complain. |/// / ////| | Fax: +27 11 807 2594 |If it's fast, the users keep quiet.|// / /////| |Cell: +27 83 250 2325 |Therefore, "No news: travels fast"!|/ ////////| +----------------------+-----------------------------------+-----------+