RE: Onmode -F . . . oops!

Actually, three AF files were created. The assert fail happened on a very innocent SELECT statement. -----Original Message----- From: David Williams [mailto:djw@smooth1.demon.co.uk] Sent: Saturday, February 03, 2001 9:49 AM To: informix-list@iiug.org Subject: Re: Onmode -F . . . oops! In article <959q5h$d6v$1@news.xmission.com>, John Carlson <John_Carlson@whsmithusa.com> writes > >IDS: 7.30.uc7 -- soon to be 9.21 (32-bit HP 11.0) >OS: HPUX 11.0 -- processors are 64-bit > >Onmode -F is a wonderful tool to free up unused memory, especially if the >reason for the allocated memory is transitory. Under HP 10.20, I've never >had a problems with it. Until now . . . . > >I noticed a few extra memory segments allocated just today. Without much >worry, I executed an onmode -F and then watched my (production) engine drop >like a rock. As we haven't had many problems on HPUX 10.20, and we've been >live on this configuration for (almost) three days, I'm not quite ready to >believe that another issue is at stake here. I know that we're running a HP >10.20 port on a HP11.0 OS; this situation will change within 6-8 weeks. I >guess my questions are these: > >* Are problems with onmode -F on HPUX 11.0 a known issue? Like my >sysadmin said, it would be bad to not have a way to clean up unused memory. Was an af file produced? What what the stack trace for the thread which crashed? >* Is this an issue with a HPUX 10.20 binary on a HP 11.0 OS? >* Are there any other known gotchas out there with a 'mismatch' in app >port level and OS level? >* Are there any known issues with running a 32-bit engine on a 64-bit >OS? > >Thought I had this nailed down a while back . . . thought I'd better >double-check with others who might be doing the same thing. > >Thanks in advance! > >John Carlson >Informix Database Administrator >EDS - WHSmith USA >3200 Windy Hill Road, Suite 1500 West >Atlanta, GA 30330 > > -- David Williams

I just wouldn't run onmode -F until you get the database upgraded. I'd guess that you're having problems with differences in the way the OS handles the onmode -F. It really isn't critical that you run onmode -F anyway, as sooner or later the memory will be reclaimed by the engine anyway unless you have some process that grabs huge amounts of memory and then releases it, but never really quits (some sort of daemon process, perhaps). onmode -F merely forces it to happen right now. In article <95mlal$qkb$1@news.xmission.com>, John Carlson <John_Carlson@whsmithusa.com> wrote: > > Actually, three AF files were created. The assert fail happened on a very > innocent SELECT statement. > > -----Original Message----- > From: David Williams [mailto:djw@smooth1.demon.co.uk] > Sent: Saturday, February 03, 2001 9:49 AM > To: informix-list@iiug.org > Subject: Re: Onmode -F . . . oops! > > In article <959q5h$d6v$1@news.xmission.com>, John Carlson > <John_Carlson@whsmithusa.com> writes > > > >IDS: 7.30.uc7 -- soon to be 9.21 (32-bit HP 11.0) > >OS: HPUX 11.0 -- processors are 64-bit > > > >Onmode -F is a wonderful tool to free up unused memory, especially if the > >reason for the allocated memory is transitory. Under HP 10.20, I've never > >had a problems with it. Until now . . . . > > > >I noticed a few extra memory segments allocated just today. Without much > >worry, I executed an onmode -F and then watched my (production) engine drop > >like a rock. As we haven't had many problems on HPUX 10.20, and we've been > >live on this configuration for (almost) three days, I'm not quite ready to > >believe that another issue is at stake here. I know that we're running a > HP > >10.20 port on a HP11.0 OS; this situation will change within 6-8 weeks. I > >guess my questions are these: > > > >* Are problems with onmode -F on HPUX 11.0 a known issue? Like my > >sysadmin said, it would be bad to not have a way to clean up unused memory. > > Was an af file produced? What what the stack trace for the thread > which crashed? > > >* Is this an issue with a HPUX 10.20 binary on a HP 11.0 OS? > >* Are there any other known gotchas out there with a 'mismatch' in app > >port level and OS level? > >* Are there any known issues with running a 32-bit engine on a 64-bit > >OS? > > > >Thought I had this nailed down a while back . . . thought I'd better > >double-check with others who might be doing the same thing. > > > >Thanks in advance! > > > >John Carlson > >Informix Database Administrator > >EDS - WHSmith USA > >3200 Windy Hill Road, Suite 1500 West > >Atlanta, GA 30330 > > > > > > -- > David Williams > -- # unrm / ksh: unrm: not found # man cpio Sent via Deja.com http://www.deja.com/

In article <95mlal$qkb$1@news.xmission.com>, John Carlson <John_Carlson@whsmithusa.com> writes > >Actually, three AF files were created. The assert fail happened on a very >innocent SELECT statement. The Assert failure message should mention a /tmp/af.file What does it say? -- David Williams