From: Jakob Oestergaard <jakob@unthought.net>
To: linux-kernel@vger.kernel.org
Subject: 2.4.25 - large inode_cache
Date: Thu, 26 Feb 2004 02:33:14 +0100 [thread overview]
Message-ID: <20040226013313.GN29776@unthought.net> (raw)
Dear list,
I have this dual athlon box with 1G memory and a 150G filesystem (four
IDE disks on promise controllers, SW RAID-0+1, ext3fs, user quotas,
HIGHMEM set, plain 2.4.25).
A fresh boot after an unclean shutdown, caused it to run quotacheck on
the filesystem, nothing odd about that.
However, after quotacheck completed, I got "3 order allocation failed"
messages. They kept coming, about one per second. This was happening as
the box entered single user mode - and the messages continued.
>From /proc/slabinfo, I got:
inode_cache 1208571 1208571 512 172653 172653 1 : 124 62
dentry_cache 736 268680 128 27 8956 1 : 252 126
To me it looks like this could be at least a part of the explanation for
the memory shortage - am I completely off track here?
After a clean boot with no quotacheck, it looks like:
inode_cache 3829 3829 512 547 547 1 : 124 62
dentry_cache 4710 4710 128 157 157 1 : 252 126
Besides, after a few days of running, the machine will use about 100MB
of memory for cache, 100MB for buffers, about 100MB for userspace, and
the remaining 600-700 MB of memory for inode_cache and dentry_cache.
It's a file server, and its performance is far from stellar. After
seeing that only about 200MB total was used for cache/buffers, I started
digging into slabinfo.
Is this a known problem? (yes, I know that there's been quite a bit
back and forward on this list about the slabs, but I'm not sure what the
current status is - as far as I know, the only known long-standing
problems with the 2.4 series VM should have been fixed in 2.4.25).
If not, is there anything I can do to actually find out what the cause
of my poor cache sizes are? I believe that a box which does almost
strictly NFS file serving and has 1G of memory, should use more than
100M for cache. Or is that just me? (no, there is no significant
amount of free memory, virtually all is used - but not by cache and not
by userspace).
If it is a known problem - any workarounds?
Would 2.6 solve it?
Thanks, for any input you may have,
/ jakob
next reply other threads:[~2004-02-26 1:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-26 1:33 Jakob Oestergaard [this message]
2004-02-26 11:19 ` 2.4.25 - large inode_cache Christian Leber
2004-02-26 13:08 ` Marcelo Tosatti
2004-02-26 13:03 ` Jakob Oestergaard
2004-02-26 14:23 ` Marcelo Tosatti
2004-02-26 13:53 ` Jakob Oestergaard
2004-02-26 17:43 ` Andreas Dilger
2004-02-26 20:43 ` Marcelo Tosatti
2004-02-27 12:27 ` Jakob Oestergaard
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=20040226013313.GN29776@unthought.net \
--to=jakob@unthought.net \
--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