From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Josh Grebe <squash@primary.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question about memory usage in 2.4 vs 2.2
Date: Tue, 20 Mar 2001 13:54:49 -0500 [thread overview]
Message-ID: <20010320135449.A24252@cs.cmu.edu> (raw)
In-Reply-To: <200103190207.UAA13397@senechalle.net> <Pine.LNX.4.21.0103201038140.2405-100000@scarface.primary.net>
In-Reply-To: <Pine.LNX.4.21.0103201038140.2405-100000@scarface.primary.net>; from squash@primary.net on Tue, Mar 20, 2001 at 11:01:52AM -0600
On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
>
> I have a server farm made of identical hardware running pop3 and imap mail
> functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> noticed that according to free, our memory utilization went way up. Here
> is the output of free on the 2.4.2 machine:
> total used free shared buffers cached
> Mem: 513192 492772 20420 0 1684 263188
> -/+ buffers/cache: 227900 285292
> Swap: 819304 540 818764
>
>
> On the 2.2..18 machine:
> total used free shared buffers cached
> Mem: 517256 351280 165976 19920 82820 186836
> -/+ buffers/cache: 81624 435632
> Swap: 819304 0 819304
>
>
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.
What does /proc/slabinfo report for the number of pages locked down in
the inode and dentry caches? My machine has pretty much every inode in
memory and is using close to 50% of my memory for these (214MB/512MB).
These caches do not seem to be counted towards 'reclaimable' memory by
the new VM and are only pruned when _all_ other attempts to free up
memory have failed.
This becomes very noticeable on a not very fast, small memory machine
(i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
becomes unusable after an updatedb run.
Jan
next prev parent reply other threads:[~2001-03-20 18:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 2:07 /proc/cpuinfo for Intel P4 D850GB asenec
2001-03-19 2:33 ` davej
2001-03-19 3:14 ` 2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb Shawn Starr
2001-03-19 12:02 ` /proc/cpuinfo for Intel P4 D850GB David Weinehall
2001-03-19 21:58 ` 2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb Shawn Starr
2001-03-20 17:01 ` Question about memory usage in 2.4 vs 2.2 Josh Grebe
2001-03-20 17:32 ` Jakob Østergaard
2001-03-20 20:29 ` Josh Grebe
2001-03-21 19:16 ` Jan Harkes
2001-03-21 19:54 ` Rik van Riel
2001-03-20 18:54 ` Jan Harkes [this message]
2001-03-20 20:29 ` Josh Grebe
2001-03-20 22:18 ` Rik van Riel
2001-03-20 22:29 ` Juha Saarinen
2001-03-21 9:28 ` Zou Min
2001-03-21 9:51 ` Andreas Dilger
2001-03-21 10:56 ` Zou Min
-- strict thread matches above, loose matches on Subject: below --
2001-03-21 10:14 Manfred Spraul
2001-03-21 17:42 ` Josh Grebe
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=20010320135449.A24252@cs.cmu.edu \
--to=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=squash@primary.net \
/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.