From: Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>,
Jens Axboe <axboe@suse.de>,
Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: kblockd/1: page allocation failure in 2.6.9
Date: Sun, 26 Dec 2004 23:31:24 +0100 [thread overview]
Message-ID: <41CF3BBC.9010304@bio.ifi.lmu.de> (raw)
In-Reply-To: <1104076000.5268.18.camel@mulgrave>
James Bottomley wrote
> The kblockd message is just a symptom of the machine running low on
> memory and starting to fail normal kernel memory allocations. There's
> always a potential for hangs when something can't allocate memory:
> usually it's in the middle of a transaction and just forgets about it;
> what should happen (as we just verified SCSI does) is that the
> transaction should be rolled back and retried.
Ah, ok. Now at least I know what this messages mean! Indeed, as I wrote
in the first mail, 1.7GB of the 2GB memory of the machine were in use,
and that was "real" usage, i.e., without any buffers. But that was already
three hours after the failure occured. Unfortunately we didn't check what
process was using how much memory because we just rebooted as quick as
possible to get the server processes running again.
Might be a memory leak in some application, because neither the mysql
database nor the tomcat server should take more than a few hundred MB
of memory alltogether. I will ask the user to redo the mysql database
dump, maybe that was it and we can trigger the failure again. But that
will take two weeks until everyone is back in office :-)
>
>>- there were no messages "around" the kblockd messages in /var/log/messages
>> but the usual ones about remote ssh login, cron jobs etc., but the messages
>> were all more than 10 minutes "away" before and after the kblockd happened.
>
> That's unfortunate. It means that whatever caused this left no trace.
> The best working theory is still a memory allocation failure somewhere.
> If it occurs again, could you get a full system process trace (<alt>-
> <sysrq>-t) and send that? That might give a better clue as to what went
> on.
Yes, sure! If we can reproduce it, I will send the log and try to figure
out which process takes so much memory. Thanks for your help!
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: -4054
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
next prev parent reply other threads:[~2004-12-26 22:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-21 7:39 kblockd/1: page allocation failure in 2.6.9 Frank Steiner
2004-12-23 11:26 ` Frank Steiner
2004-12-23 15:51 ` Denis Vlasenko
2004-12-23 15:55 ` Frank Steiner
2004-12-24 13:20 ` Jens Axboe
2004-12-24 19:28 ` James Bottomley
2004-12-25 22:49 ` Frank Steiner
2004-12-26 15:46 ` James Bottomley
2004-12-26 22:31 ` Frank Steiner [this message]
2005-01-10 9:19 ` Frank Steiner
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=41CF3BBC.9010304@bio.ifi.lmu.de \
--to=fsteiner-mail@bio.ifi.lmu.de \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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