Re: onbar -b -w

Hi, I run the nightly backup through cron. It is not any shell process or child process. I know this for sure. Because three new proc's show up as being blocked even if I simply ran this on the command line, host#onbar -b -w The command finishes successfully. So far so good. Once you run a vmstat 5 performance monitoring command. If you look under the column labeled b which stands for blocked in vmstat, you would see three procs in blocked state from then on. Run the command again. The number increments to n+3. Initially I thought it was a disk I/O problem, that was putting the procs in a blocked state. Later I noticed that even when there is nill activity on the system the blocked procs remain. Hope this additional information helps. Zombie... In article <4121B449.510BCEFC@chello.at>, Richard Kofler says... > >zombie wrote: >> >> It certainly is not a problem with informix. It is running well. >> However the OS shows these procs as being in a wait state infinitely. >> need to resolve the problem soon. By the end of every week there are 21 >> additional procs in wait state. >> >>In article <c46e3ec5.0408160551.5d973e8@posting.google.com>, Brice Avila says... >> > >> >It may be by design. During archive checkpoints the instance is >> >temporarily halted from updates/inserts . . . I don't know the >> >Informix architecture as well as I'd like to, but these three blocked >> >processes may be part of the archive checkpoint? Can you restore from >> >the backup? >> > >> >Informix does a lot of complaining when something goes wrong, and if >> >usually if there isn't a warning/error, there isn't a problem. Hope >> >this helps. >> > >> >Brice Avila >> >Minneapolis, Minnesota >> > >> > >> >zombie <zombie_member@newsguy.com> wrote in message >> >news:<cfphv70qp8@drn.newsguy.com>... >> >> Hi DBA's, >> >> I have an installation of informix 9.40 FC1. >>>> Every time we run the nightly backup onbar -b -w , it adds three processes to >> >> the list of blocked processes in the O/S. >> >> >>>>Can anyone guide me towards troubleshooting this problem. The backup completes >> >> successfully. >> >> >> >> There are no errors in the online.log file or the bar_act.log file. >>>> The only problem, when I run a vmstat the number of processes in the blocked >> >> state increases by three. Any idea whats going on here? >> >> >> >> Any help is greatly appreciated! >> >> >> >> +Zombie > >How *exactly* do you run the nightly backup: >a shell script in cron, a TSM TIVOLI module >starting a shell, ..... there are so many ways >to do it! > >Often zombified processes are simply childs of shell >processes, where the parent shell does neither >hand the child over to the init process, nor does >it execute the wait statement -> orphaned child > >So I need details please, then maybe I can help. > >dic_k

Folks, For anyone else who faces this problem, I would like to post how we resolved this problem. The problem had nothing to do with informix. The problem was associated with solaris and interoperability with veritas file system. SUN changed the kernel to support new features in their multi threaded CPU's. Which resulted in the veritas file system updating wrong kernel parameters after the patch is installed. So everytime you read or write to the veritas file system it would increment the kernel counter for blocked processes by mistake, and hence the misleading information of processes being blocked. In my case I was doing a backup (onbar -b -w) to a disk mounted vxfs file system. Hence everytime we did a backup, the counter indicating the number of blocket procs in solaris was wrongly updated by vxfs. Last night when I did a copy or a move from the vxfs directory the blocked proc count increased to 28,0000 etc, driving me nuts. Anywayz the bug ID at sun associated with this bug is. bigid:4978228 This happens on Solaris 8 with kernel patch revision greater than 28. There is no fix for this problem from Veritas or Sun so far. Thanks, zombie In article <cfud860uft@drn.newsguy.com>, zombie says... > >Hi, > >I run the nightly backup through cron. It is not >any shell process or child process. I know this for sure. >Because three new proc's show up as being blocked >even if I simply ran this on the command line, > >host#onbar -b -w > >The command finishes successfully. >So far so good. > >Once you run a vmstat 5 performance monitoring command. >If you look under the column labeled b which stands for >blocked in vmstat, you would see three procs in blocked state >from then on. Run the command again. The number increments to n+3. > >Initially I thought it was a disk I/O problem, that was putting the >procs in a blocked state. Later I noticed that even when there is nill >activity on the system the blocked procs remain. > >Hope this additional information helps. > >Zombie... > > > >In article <4121B449.510BCEFC@chello.at>, Richard Kofler says... >> >>zombie wrote: >>> >>> It certainly is not a problem with informix. It is running well. >>> However the OS shows these procs as being in a wait state infinitely. >>> need to resolve the problem soon. By the end of every week there are 21 >>> additional procs in wait state. >>> >>>In article <c46e3ec5.0408160551.5d973e8@posting.google.com>, Brice Avila says... >>> > >>> >It may be by design. During archive checkpoints the instance is >>> >temporarily halted from updates/inserts . . . I don't know the >>> >Informix architecture as well as I'd like to, but these three blocked >>> >processes may be part of the archive checkpoint? Can you restore from >>> >the backup? >>> > >>> >Informix does a lot of complaining when something goes wrong, and if >>> >usually if there isn't a warning/error, there isn't a problem. Hope >>> >this helps. >>> > >>> >Brice Avila >>> >Minneapolis, Minnesota >>> > >>> > >>> >zombie <zombie_member@newsguy.com> wrote in message >>> >news:<cfphv70qp8@drn.newsguy.com>... >>> >> Hi DBA's, >>> >> I have an installation of informix 9.40 FC1. >>>>>Every time we run the nightly backup onbar -b -w , it adds three processes to >>> >> the list of blocked processes in the O/S. >>> >> >>>>>Can anyone guide me towards troubleshooting this problem. The backup completes >>> >> successfully. >>> >> >>> >> There are no errors in the online.log file or the bar_act.log file. >>>>>The only problem, when I run a vmstat the number of processes in the blocked >>> >> state increases by three. Any idea whats going on here? >>> >> >>> >> Any help is greatly appreciated! >>> >> >>> >> +Zombie >> >>How *exactly* do you run the nightly backup: >>a shell script in cron, a TSM TIVOLI module >>starting a shell, ..... there are so many ways >>to do it! >> >>Often zombified processes are simply childs of shell >>processes, where the parent shell does neither >>hand the child over to the init process, nor does >>it execute the wait statement -> orphaned child >> >>So I need details please, then maybe I can help. >> >>dic_k >

zombie wrote: > For anyone else who faces this problem, I would like to post how we resolved > this problem. > > The problem had nothing to do with informix. > The problem was associated with solaris and interoperability with veritas file > system. [...] Dear Zombie, Thanks for the update and resolution. A situation like that with 4 parties involved - you, Sun, Veritas and IBM/Informix - is always incredibly hard to resolve; well done on doing so. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/