[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Finding the Bottleneck



Hi,

I agree with you... it seems more and more likely that the Disks are the
limiting factor here.

I guess the next big thing to do would be to run some form of Raid
(software or hardware) for the mail queue.

Does anyone know of a cheap but adequate raid hardware solution? The one's
I've seen seem to cost quite a bit. I know that the common cheap ATA100
Raid cards available now (using the Highpoint HPT370) don't work properly
on Linux beacuse of the bad driver support. Anyone know of an alternative?

Actually... do you think setting up a seperate box (connected via NFS)
PURELY for mail queue processing would help at all? Or would the
bottleneck then be shifted to NFS?

Sincerely,
Jason

----- Original Message -----
From: "Russell Coker" <russell@coker.com.au>
To: "Jason Lim" <maillist@jasonlim.com>; <debian-isp@lists.debian.org>
Sent: Thursday, June 07, 2001 3:21 PM
Subject: Re: Finding the Bottleneck


On Thursday 07 June 2001 00:11, Jason Lim wrote:
>  05:51:18 up 5 days, 22:38,  1 user,  load average: 6.60, 7.40, 6.51
> 119 processes: 106 sleeping, 11 running, 2 zombie, 0 stopped
> CPU states:  16.4% user,  18.3% system,   0.0% nice,  65.3% idle
> Mem:    128236K total,   124348K used,     3888K free,    72392K buffers
> Swap:   289160K total,        0K used,   289160K free,     9356K cached
>
> And of "qmail-qstat":
> sh-2.05# qmail-qstat
> messages in queue: 108903
> messages in queue but not yet preprocessed: 19537
>
> Swap is on Disk 1, because mail queue/spool is on Disk 2.
>
> I also already added the "-" in front of most entries except the
emergency
> or critical ones (if I didn't do it, the load was way higher just
writing
> the log files).
>
> Concerning the mail queue and spool being on the same disk, the reason
is
> that there is virtually no emails incoming, 99.999% outgoing.
>
> About running software raid... I've heard that the CPU usage is
increased
> dramatically if you use any form of software raid. Is that true?
> Actually... i doubt the customer would be willing to pay us to implement
> this for him on a hardware level. Good raid cards with good amounts of
ram
> don't come cheap last time I checked... :-/

CPU usage isn't increased that much, and as you're only using 30% of the
CPU
time it shouldn't be problem if you use more anyway...

Disk access is the main bottleneck, anything that alleviates it is
something
you want to do.

--
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page


--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org






Reply to: