From: "Miquel van Smoorenburg" <miquels@cistron.nl>
To: linux-kernel@vger.kernel.org
Subject: 2.5.74-mm3 OOM killer fubared ?
Date: Thu, 10 Jul 2003 11:14:59 +0000 (UTC) [thread overview]
Message-ID: <bejhrj$dgg$1@news.cistron.nl> (raw)
I was running 2.5.74 on our newsfeeder box for a day without
problems (and 2.5.72-mm2 for weeks before that).
Now with 2.5.74-mm3 (booted 11 hours ago) it keeps killing processes
for no apparent reason:
Jul 10 11:59:01 quantum kernel: Out of Memory: Killed process 9952 (innfeed).
Jul 10 12:25:48 quantum kernel: Out of Memory: Killed process 10498 (innfeed).
Jul 10 12:25:48 quantum kernel: Fixed up OOM kill of mm-less task
Jul 10 12:45:41 quantum kernel: Out of Memory: Killed process 11894 (innfeed).
Jul 10 12:47:14 quantum kernel: Out of Memory: Killed process 13128 (innfeed).
Jul 10 12:53:09 quantum kernel: Out of Memory: Killed process 13221 (innfeed).
Jul 10 12:55:12 quantum kernel: Out of Memory: Killed process 13649 (innfeed).
I check seconds before the last kill:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
news 13649 0.2 0.1 60368 1108 ? SN 12:53 0:00 innfeed -y
# free
total used free shared buffers cached
Mem: 1035212 1030104 5108 0 548208 307148
-/+ buffers/cache: 174748 860464
Swap: 996020 41708 954312
Enough memory free, no problems at all .. yet every few minutes
the OOM killer kills one of my innfeed processes.
I notice that in -mm3 this was deleted relative to -vanilla:
-
- /*
- * Enough swap space left? Not OOM.
- */
- if (nr_swap_pages > 0)
- return;
.. is that what causes this ? In any case, that should't vene matter -
there's plenty of memory in this box, all buffers and cached, but that
should be easily freed ..
Related mm question - this box is a news server, which does a lot
of streaming I/O, and also keeps a history database open. I have the
idea that the streaming I/O evicts the history database hash and
index file caches from memory, which I do not want. Any chance of
a control on a filedescriptor that tells it how persistant to be
in caching file data ? E.g. a sort of "nice" for the cache, so that
I could say that streaming data may be flushed from buffers/cache
earlier than other data (where the other data would be the
database files) ?
Mike.
next reply other threads:[~2003-07-10 11:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-10 11:14 Miquel van Smoorenburg [this message]
2003-07-10 11:27 ` 2.5.74-mm3 OOM killer fubared ? William Lee Irwin III
2003-07-10 12:54 ` Miquel van Smoorenburg
2003-07-10 13:34 ` Richard B. Johnson
2003-07-10 13:45 ` Miquel van Smoorenburg
2003-07-10 14:32 ` Rik van Riel
2003-07-10 17:43 ` Mikulas Patocka
2003-07-10 15:56 ` William Lee Irwin III
2003-07-10 23:05 ` Miquel van Smoorenburg
2003-07-11 1:01 ` William Lee Irwin III
2003-07-10 17:38 ` Andrew Morton
2003-07-10 23:31 ` Miquel van Smoorenburg
2003-07-10 17:46 ` Mikulas Patocka
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='bejhrj$dgg$1@news.cistron.nl' \
--to=miquels@cistron.nl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.