mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rolf Lear <rolf-linux@bits.dyndns.org>
To: matt@bodgit-n-scarper.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Where's all my memory going?
Date: 11 Jan 2002 15:30:34 -0000	[thread overview]
Message-ID: <20020111153034.11168.qmail@bits.dyndns.org> (raw)
In-Reply-To: %3C20020109173633.A26559%40mould.bodgit-n-scarper.com%3E%20from%20Matt%0A%20%20%20%20Dainty%20on%20Wed%2C%209%20Jan%202002%2017%3A36%3A33%20%2B0000%0A


Matt Dainty <matt@bodgit-n-scarper.com> writes:
>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.
>
....

qmail is very file intensive (which is a good thing ...), and RAID5 is very resource intensive (every write to RAID5 involves a number of reads and a write).

It is quite conceivable that the data volume (throughput) generated by the tests is too large for the throughput of your RAID system. From your mail I understand that the mails are being delivered locally to the RAID5 disk array.

One explaination for your results are that your qmail queue is being filled (by qmail-smtpd) at the rate of the network (presumably 100Mbit or about 10-12MiB/s). This queue is then delivered locally to the RAID5. Files in the queue do not last long (are created and then deleted, and the cache probably never gets flushed to disk ...). Delivered e-mails fill the cache though, and the kernel at some point will begin flushing these cache entries to disk. At some point (and I am guessing this is your 35-40 minute point) all pages in the cache are dirty (i.e. the kernel has not been able to write the cache to disk as fast as it is being filled ...). This will cause the disk to become your bottleneck.

This is based on the assumption that the RAID5 is slower than the network. In my experience, this is often the case. A good test for this would be tools like bonnie++, or tools like vmstat. On a saturated raid array with a cache, it is typical to get 'vmstat 1' output which shows rapid bursts of data writes (bo's), followed by periods of inactivity. A longer vmstat like 'vmstat 10' will probably even out these bursts, and show an 'averaged' throughput of your disks.

It is possible that I am completely off base, but I have been battling similar problems myself recently, and discovered to my horror that RAID5 disk arrays are pathetically slow. Check your disk performance for the bottleneck.

Rolf

             reply	other threads:[~2002-01-11 15:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-11 15:30 Rolf Lear [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-09 17:36 Matt Dainty
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

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=20020111153034.11168.qmail@bits.dyndns.org \
    --to=rolf-linux@bits.dyndns.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@bodgit-n-scarper.com \
    /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®