RE: Onmode -F . . . oops!

That's my thought too. IDS 9.21 will be online in a week or so (test mode). -----Original Message----- From: mars1972@my-deja.com [mailto:mars1972@my-deja.com] Sent: Monday, February 05, 2001 3:44 PM To: informix-list@iiug.org Subject: RE: Onmode -F . . . oops! 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/

I have seen 9.21 crash during an onmode -F. I even have the assert to prove it ;) Will In article <95p4dt$mt7$1@news.xmission.com>, John Carlson <John_Carlson@whsmithusa.com> wrote: > > That's my thought too. IDS 9.21 will be online in a week or so (test mode). > > -----Original Message----- > From: mars1972@my-deja.com [mailto:mars1972@my-deja.com] > Sent: Monday, February 05, 2001 3:44 PM > To: informix-list@iiug.org > Subject: RE: Onmode -F . . . oops! > > 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/ > Sent via Deja.com http://www.deja.com/

In the year of Our Lord Fri, 09 Feb 2001 16:44:35 GMT, William Rice <ricew@operamail.com> spake, saying: >I have seen 9.21 crash during an onmode -F. I even have the assert to >prove it ;) So have I, on NT. :-( >In article <95p4dt$mt7$1@news.xmission.com>, > John Carlson <John_Carlson@whsmithusa.com> wrote: >> >> That's my thought too. IDS 9.21 will be online in a week or so (test >mode). >> >> -----Original Message----- >> From: mars1972@my-deja.com [mailto:mars1972@my-deja.com] >> Sent: Monday, February 05, 2001 3:44 PM >> To: informix-list@iiug.org >> Subject: RE: Onmode -F . . . oops! >> >> 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/ >> > > >Sent via Deja.com >http://www.deja.com/