From: "Keith Mannthey" <kmannth@gmail.com>
To: "Manish Neema" <Manish.Neema@synopsys.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: System hang problem.
Date: Tue, 3 Oct 2006 16:35:25 -0700 [thread overview]
Message-ID: <a762e240610031635v73fdf36fk80005c4967b38410@mail.gmail.com> (raw)
In-Reply-To: <C9A861D62D068643A0F4A7B1BCB38E2C0327B5A0@US01WEMBX1.internal.synopsys.com>
On 10/3/06, Manash Neema <Manish.Neema@synopsys.com> wrote:
> Sorry, I've lost my patience with RedHat so posting here....
>
> We see this problem frequently on RHEL3.0 U5 and U7. System would
> completely hang upon memory shortage. The only option left is
> power-cycle (or 'sysrq + b'). System hang occurs with any of the below 3
> overcommit settings:
In general RHEL3 isn't to good at returning from "memory shortage"
once the oom comes out I would consider the system trashed. You need
to manage it better so you don't overcommit the system resouces.
> - default (heuristic) overcommit (overcommit_memory=0)
> - no overcommit handling by kernel (overcommit_memory=1)
> - restrictive overcommit with ratio=100% (overcommit_memory=2;
> overcommit_ratio=100)
>
> RHEL3.0 U3 would generate an OOM kill "each and every time" it sensed
> system hang but due to other bugs, we had to move away from it. RedHat
> calls the timely (at least for us) invocation of OOM in U3 a buggy
> implementation and the delayed OOM kill in U5 and U7 the right
> implementation (which we rarely get to see resulting in at least 5
> systems hanging daily!)
If you are using too much memory you are using too much memory. RHEL3
may not be recovering well (by your standards) from this. (perhaps not
any kernel for that matter)
> Changing overcommit to 2 (and ratio to any where from 1 to 99) would
> result in certain OS processes (automount daemon for e.g.) getting
> killed when all the allowed memory is committed. What is the point in
> reserving some memory if a random root process would get killed leaving
> the system in a totally unknown state?
Choosing who to kill is a hard decision. Stay away from the kernel
oom killer is is a wiley beast.
> Any suggestions on how we can prevent system-hang + not have automount
> (and any other root process) die?
There are a whole bunch of /proc knobs (more than just the overcommit)
in RHEL3 that you may dive into. You would need to get your RHEL
support to help you out with that. It is really hard to say what the
deal is but if you application is using too much memory oom is
inevitable.
As far as having an oom killer that meets you standards... You have
to talk to Redhat about that.
At a high level I would say add more memory (or reduce the amount
used my the applications) to the box if you can't find the right /proc
bit to work. Sounds like something has to give.
good luck,
Keith
next prev parent reply other threads:[~2006-10-03 23:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 22:07 Manish Neema
2006-10-03 23:35 ` Keith Mannthey [this message]
2006-10-04 0:33 ` Alan Cox
2006-10-04 0:07 Manish Neema
2006-10-04 0:49 ` Alan Cox
2006-10-04 3:26 ` Willy Tarreau
2006-10-04 9:53 ` Jarek Poplawski
2006-10-04 5:44 Manish Neema
2006-10-04 14:24 Al Boldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a762e240610031635v73fdf36fk80005c4967b38410@mail.gmail.com \
--to=kmannth@gmail.com \
--cc=Manish.Neema@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®