onmode -F: is it just HP-UX?

Re. my previous issue with loads of V segments; We're on HP-UX11i and IDS9.30, and onmode -F does absolutely *squat* with regards to releasing any segments. Out of the segments we had, there were plenty with just 2 or 3 blocks used and if you added it all up you could have consolidated the part-used blocks into just a couple of segments with a suitable cleanup IF IT WAS AVAILABLE!; obviously the process that asked for them and then finished off with them left some trash behind. Is IDS10.00 any better at segment management/onmode -F implementation that the one we have? 9.30 just seems so messy........

It's the same on IDS 10 under Linux. -- Neil Truby t:01932 724027 Director m:07798 811708 Ardenta Limited e:neil.truby@ardenta.com <malc_p@btinternet.com> wrote in message news:1161007916.881358.219060@m73g2000cwd.googlegroups.com... > Re. my previous issue with loads of V segments; We're on HP-UX11i and > IDS9.30, and onmode -F does absolutely *squat* with regards to > releasing any segments. Out of the segments we had, there were plenty > with just 2 or 3 blocks used and if you added it all up you could have > consolidated the part-used blocks into just a couple of segments with a > suitable cleanup IF IT WAS AVAILABLE!; obviously the process that asked > for them and then finished off with them left some trash behind. > Is IDS10.00 any better at segment management/onmode -F implementation > that the one we have? 9.30 just seems so messy........ >

malc_p@btinternet.com wrote: > Re. my previous issue with loads of V segments; We're on HP-UX11i and > IDS9.30, and onmode -F does absolutely *squat* with regards to > releasing any segments. Out of the segments we had, there were plenty > with just 2 or 3 blocks used and if you added it all up you could have > consolidated the part-used blocks into just a couple of segments with a > suitable cleanup IF IT WAS AVAILABLE!; obviously the process that asked > for them and then finished off with them left some trash behind. > Is IDS10.00 any better at segment management/onmode -F implementation > that the one we have? 9.30 just seems so messy........ > onmode -F is not a "garbage" collector (i.e. it will not trawl through all the V segments and try and move used bits into a lower addressed segment). If there is ANY memory in the extra V segments which is used it will not release the V segment (or the segments below). More importantly is to : a. Configure SHMVIRTSIZE correctly. b. Configure SHMADD correctly (i.e. avoid loads of little segments). Why not configure "I think I use about this much SHMVIRTSIZE plus 20%" for the initial virtual segment, and then configure SHMADD to be 10% of that. If you get ANY extra segments, then you know that you have either under configured SHMVIRTSIZE, or a process has grabbed "more than a little". onstat -g aft may give you a clue (by the address) as to what is being used in the virtual segments which cannot be released.

TBP (The Big Potato) wrote: > onmode -F is not a "garbage" collector (i.e. it will not trawl through all the V segments and try and move used bits into a lower > addressed segment).> > If there is ANY memory in the extra V segments which is used it will not release the V segment (or the segments below). > > More importantly is to : > > a. Configure SHMVIRTSIZE correctly. > b. Configure SHMADD correctly (i.e. avoid loads of little segments). I quite agree > Why not configure "I think I use about this much SHMVIRTSIZE plus 20%" for the initial virtual segment, and then configure SHMADD to > be 10% of that. Which is what we've done - the server can run for over a couple of hundred days quite happily with no added segments; then just occasionallly a process goes rogue, or a new chunk of code goes live that's been inadequately tested and BANG loads of new Vsegs. > If you get ANY extra segments, then you know that you have either under configured SHMVIRTSIZE, or a process has grabbed "more than > a little". I think we've got a pretty good configuration here, the problem we had the other day was a process that suddenly grabbed 80 segments as in: "Dynamically allocated new virtual shared memory segment (size 8192KB)" and then ran aground with "hpkaioaddseg: ASYNC_ADDSEG failed, errno = 7 Arg list too long" obviously having hit an HP-UX limit; it would have probably have continued blithely otherwise! There's no mitigating this sort of thing. It shouldn't happen, but it does. It's be nice to have onmode -F clean up completely, that's all. > onstat -g aft may give you a clue (by the address) as to what is being used in the virtual segments which cannot be released. I'll do that, thanks. I'll also set SHMADD to 64Mb (up from 8) in future.