Re: Dynamically adding shared memory segs

June Tong schrieb: > > Martin Berns wrote: > > > Mark D. Stock schrieb: > > > > > > Martin Berns wrote: > > > > > > > > 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. > > [snip] > > 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! > > As Mark said, if it's just once -- someone ran a HUGE query that allocated a whole bunch of virtual > segments that are now languishing in disuse -- then okay, free them THIS TIME with a one-off onmode -F. > > If you have to run onmode -F every x minutes, then you're really doing yourself a disservice. OnLine > obviously NEEDS that memory, and it's just allocating it again every few minutes, after you've gone and > freed it. You are missing one point: onmode -F is freeing a c t u a l l y n o t n e e d e d session-memory! Especially in a Client-Server-Environment, where users start the application in the morning via autostart and exit in the evening, doing one,two,three memory-intensive-SQL allover the day: Whether this memory is needed in the next few minutes or never again, is depending on what the user will do. Informix can't know, so it is correct that informix won't free this by itself. Immagine a community of hundred users, who have to deal with a 10 MB SHVIRTSIZE and after login a session is on say total memory=50.000 and used memory=45.000. If all sessions were in this login-only state, you should have 50% of your memory allocated. Lets say one user-action boosts the session memory to tm=1.000.000 um=90.000. Just ten people doing this will lead to an additional segment allocation. Every new login-session's memory will now be located in this additonal segment! So this segment can't be freed until these users logout. We had to deal with a similar environment at one of our customers and after running onmode -F every 5 minutes by cron we never again saw informix allocating a new segment! Before, they had an average of 8 additional 8MB-segments at the end of a day, each used by less than 10%! > This constant freeing and re-allocating of memory is going to be a real performance drain, not > to mention being completely futile. You're not saving yourself any paging, because OnLine is just > re-allocating them after you've freed them. This is correct in an environment whith hundreds of users each doing thousands of similar transactions per day, but as you may see above this is n o general rule! > As Mark said, tune your SHMVIRTSIZE and SHMADD parameters so that OnLine doesn't need to be constantly > adding more segments, and so that it doesn't use more than what it really needs. If you don't have enough > memory, get more, or stop your users from running big memory hog queries, or something. Running constant > onmode -F's isn't getting you anywhere. Again this is n o general rule! hth martin