Re: Dynamically adding shared memory segs

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. 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. 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. June -- june_t@hotmail.com Lost in the wilds of Palo Alto, living on Plain M&M's