Re: IDS, Linux and OOM killer
Sebastian, Norma J. a formulￜ la demande :
> Philippe,
>
> You are correct, onbar -w (whole) will run serially.
>
> You said
> The server is dedicated to IDS, and the problem occurs when onbar is
> launched to backup the dbspaces. The backup process runs every night,
> and the problem occurs about twice a month.
>
>
> Are you absolutely certain the ONLY thing on this server is IDS?
Yes, I am. There is some jobs in crontab : cleaning of old backup and
temp files. Very light processes (find, rm), running once a day. The
problem does not occur when these small processes run.
> Is there some type of cron (sorry, I'm not very linux knowledgeable so I
> speak solaris) or system activity or network that also happens twice a month?
> It is indeed odd that every night the IDS onbar whole backup works fine
> except twice a month.
Except oninit and nsr* (ism processes), onbar_d is the only heavy
process that runs on the server.
I have now installed a little survey probe (a simple 'free' command in
crontab), to see how the RAM and Swap evolve in time. In particular, I
wonder why the kernel does not use the swap area. As you can see in my
first post, the swap is still around 4Gb free when the OOM problem
occurs.
> By any chance are you running something inside the DB engine twice a
> month.... some big stats job or some job that might make IDS save more in the
> temp area during the backup?
No.
> I can't help you from the o/s side.... but since you have "spikes" twice a
> month it would appear something different is happening on that server or IDS
> twice a month that is not normally happening....
>
> I hope my "thinking" here will help you spot something.
Thank you for your "thinking".
When the problem will be fixed, I shall post the solution I found.
Philippe
"philippe 写道：
"
> Sebastian, Norma J. a formulé la demande :
> > Philippe,
> >
> > You are correct, onbar -w (whole) will run serially.
> >
> > You said
> > The server is dedicated to IDS, and the problem occurs when onbar is
> > launched to backup the dbspaces. The backup process runs every night,
> > and the problem occurs about twice a month.
> >
> >
> > Are you absolutely certain the ONLY thing on this server is IDS?
>
> Yes, I am. There is some jobs in crontab : cleaning of old backup and
> temp files. Very light processes (find, rm), running once a day. The
> problem does not occur when these small processes run.
>
>
> > Is there some type of cron (sorry, I'm not very linux knowledgeable so I
> > speak solaris) or system activity or network that also happens twice a month?
> > It is indeed odd that every night the IDS onbar whole backup works fine
> > except twice a month.
>
> Except oninit and nsr* (ism processes), onbar_d is the only heavy
> process that runs on the server.
>
> I have now installed a little survey probe (a simple 'free' command in
> crontab), to see how the RAM and Swap evolve in time. In particular, I
> wonder why the kernel does not use the swap area. As you can see in my
> first post, the swap is still around 4Gb free when the OOM problem
> occurs.
>
>
> > By any chance are you running something inside the DB engine twice a
> > month.... some big stats job or some job that might make IDS save more in the
> > temp area during the backup?
>
> No.
>
> > I can't help you from the o/s side.... but since you have "spikes" twice a
> > month it would appear something different is happening on that server or IDS
> > twice a month that is not normally happening....
> >
> > I hope my "thinking" here will help you spot something.
>
> Thank you for your "thinking".
>
> When the problem will be fixed, I shall post the solution I found.
>
> Philippe
I'm not familiar with informix, but I've encountered a problem like
yours. It is: I have a oracle
server on a HP-UX, about every 10 days it will down, and the later we
found it was because
the swap, perhaps you should check your swap info and may found some
reason.
song.