linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Godfroy <godfroy@clipper.ens.fr>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: David.Madore@ens.fr
Subject: possible (ext4 related?) memory leak in kernel 2.6.26
Date: Tue, 30 Sep 2008 22:27:29 +0200	[thread overview]
Message-ID: <20080930202728.GA6358@goelette.ens.fr> (raw)

Hi lists,

I'd like to report the following problem : after ~ 10 days' uptime on a
Debian 2.6.26-1-686 kernel, my system becomes extremely sluggish and
unresponsive and the OOM-killer starts targeting even innocent processes like
identd or rsync (when the swap is disabled). The machine is low on RAM (192
MB) but this has never been a problem before. As for the slowness, strace
shows that the brk() syscall takes ages to complete; the blocking processes
are in the D state (and for some reason the kernel gives no wchan info).

Free reports a large and constantly growing 'buffers' figure (more than
50% of the available memory). No userland processes seems to be consuming
lare amounts of memory (sum of RSS in 'ps aux' is about 30 megs), and the
overall system is mostly idle.

for instance, the following command reports 

$ free ; dpkg -l '*' >/dev/null; dmesg | tail -n 2
             total       used       free     shared    buffers     cached
Mem:        190356     178920      11436          0     126104      12520
-/+ buffers/cache:      40296     150060
Swap:            0          0          0
/* Waits a minute or so */
Killed
[811245.911859] Out of memory: kill process 6639 (dpkg-query) score 7292 or a child
[811245.911972] Killed process 6639 (dpkg-query)

Config has nothing unusual except that all fs are ext4, which I am begining
to suspect may be the culprit, as every night some process stat()s and
read()s something like 850,000 files, which is maybe fs-stressing; also,
umounting then remounting /home makes the 'buffers' drop from 127304 to
55920 and partially solves the problem.

For info, on umount the last lines in the dmesg read:

[811842.209432] EXT4-fs: mballoc: 12288 blocks 12288 reqs (0 success)
[811842.209547] EXT4-fs: mballoc: 13038 extents scanned, 5902 goal hits,
6315 2^N hits, 0 breaks, 0 lost
[811842.209638] EXT4-fs: mballoc: 768 generated and it took 12577042
[811842.209695] EXT4-fs: mballoc: 1588424 preallocated, 371043 discarded
[811842.372165] kjournald2 starting.  Commit interval 5 seconds
[811842.373381] EXT4 FS on hda4, internal journal
[811842.373473] EXT4-fs: mounted filesystem with ordered data mode.
[811842.373529] EXT4-fs: file extents enabled
[811842.374013] EXT4-fs: mballoc enabled

I believe the problem appeared in 2.6.25, but I am not sure.

Regards,
Quentin Godfroy

             reply	other threads:[~2008-09-30 20:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 20:27 Quentin Godfroy [this message]
2008-09-30 21:18 ` possible (ext4 related?) memory leak in kernel 2.6.26 Theodore Tso
2008-10-02 18:36 ` Aneesh Kumar K.V

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=20080930202728.GA6358@goelette.ens.fr \
    --to=godfroy@clipper.ens.fr \
    --cc=David.Madore@ens.fr \
    --cc=linux-fsdevel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).