From: Matt Dainty <matt@bodgit-n-scarper.com>
To: linux-kernel@vger.kernel.org
Subject: Where's all my memory going?
Date: Wed, 9 Jan 2002 17:36:33 +0000 [thread overview]
Message-ID: <20020109173633.A26559@mould.bodgit-n-scarper.com> (raw)
Hi,
I've fashioned a qmail mail server using an HP NetServer with an HP NetRaid
4M & 1GB RAM, running 2.4.17 with aacraid, LVM, ext3 and highmem. The box
has 6x 9GB disks, one for system, one for qmail's queue, and the remaining
four are RAID5'd with LVM. ext3 is only on the queue disk, ext2 everywhere
else.
Before I stick the box live, I wanted to test that it doesn't fall over
under any remote kind of stress, so I've run postal to simulate lots of mail
connections.
Nothing too hard to begin with, but I'm seeing a degradation in performance
over time, using a maximum message size of 10KB, 5 simultaneous connections,
and limiting to 1500 messages per minute.
Initially the box memory situation is like this:
root@plum:~# free
total used free shared buffers cached
Mem: 1029524 78948 950576 0 26636 23188
-/+ buffers/cache: 29124 1000400
Swap: 2097136 0 2097136
...running postal, it seems to cope fine. Checking the queue using
qmail-qstat shows no messages being delayed for delivery, everything I chuck
at it is being delivered straight away.
However, over time, (30-45 minutes), more and more memory seems to just
disappear from the system until it looks like this, (note that swap is
hardly ever touched):
root@plum:~# free
total used free shared buffers cached
Mem: 1029524 1018032 11492 0 49380 245568
-/+ buffers/cache: 723084 306440
Swap: 2097136 676 2096460
...and qmail-qstat reports a few thousand queued messages. Even if I stop
the postal process, let the queue empty and start again, it never attains
the same performance as it did initially and the queue gets slowly filled.
I haven't left it long enough to see if the box grinds itself into the
ground, but it appears to stay at pretty much the same level as above, once
it gets there. CPU load stays at about ~5.0, (PIII 533), but it's still
very reponsive to input and launching stuff.
Looking at the processes, the biggest memory hog is a copy of dnscache that
claims to have used ~10MB, which is fine as I specified a cache of that size.
Nothing else shows any hint of excessive memory usage.
Can anyone offer any advice or solution to this behaviour, (or more tricks
or settings I can try)? I'd like the mail server to be able to handle 1500
messages instead of 150 a minute! :-) Any extra info required, please let me
know, I'm not sure what else to provide atm.
Cheers
Matt
--
"Phased plasma rifle in a forty-watt range?"
"Hey, just what you see, pal"
next reply other threads:[~2002-01-09 17:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-09 17:36 Matt Dainty [this message]
2002-01-09 17:47 ` Alan Cox
2002-01-09 22:36 ` Rik van Riel
2002-01-10 8:45 ` Bruce Guenter
2002-01-10 10:05 ` Andreas Dilger
2002-01-10 11:28 ` Matt Dainty
2002-01-10 14:55 ` Matt Dainty
2002-01-10 16:17 ` David Rees
2002-01-10 20:46 ` Andreas Dilger
2002-01-10 22:24 ` Bruce Guenter
2002-01-10 22:36 ` Andreas Dilger
2002-01-14 11:40 ` Matt Dainty
2002-01-10 22:18 ` Bruce Guenter
2002-01-11 15:30 Rolf Lear
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=20020109173633.A26559@mould.bodgit-n-scarper.com \
--to=matt@bodgit-n-scarper.com \
--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
all inboxes | Powered by JetHome®