On Mon, Jun 10, 2002 at 01:13:26PM +0100, Sean Rima wrote: | On Sun, 9 Jun 2002, Derrick Hudson uttered the following: | >| This is very true, 99% of the time spamd sits there waiting for | >| something to happen and then suddenly the poop hits the fan and | >| everything goes haywire. | >| | >| But if I disable spamc in Exim (I used your example config) and leave | >| dcc only I never get above a load average of 2.3 and dccd is flooding | >| with remote servers as well, pointing out that I use spamd with -L. | > | > spamd is CPU bound. dcc is I/O (network) bound. You won't see a | > system load from processes that are blocked on I/O. | | This is above me so I will accept what you say :)
To say that a program is "CPU bound" means that the CPU is the
limiting factor in its performance. You can increase your network
bandwidth, disk capacity, and disk bandwidth, etc, but SA won't run
any faster on that CPU. However, if you kept everything else the same
but increased your CPU power, you would see an improvement in SA's
performance.
OTOH, saying that DCC is I/O bound means that the limiting factor is
bandwidth. In this case it is network bandwidth. You can put a
super-powerful Athlon in that box, but DCC won't run any faster
because it mostly sits idle waiting for data to come back from the
network. However, if you got an OC3 line (or even just a DSL line)
you would see significant improvement in its speed. (I presume --
I've never tried it, but your description of the symptons lines up
with this hypothesis).
| I have currently got the mail box at 3.5 with a queue delivery of 10
| minutes, this I am increasing to 20 minutes as it hits inbounds
| anyway. Sometimes it can take me upto 30 minutes just to bring the first
| batch of mail in.
The 30 minutes includes SA scanning, right? By setting
queue_deliver_load_max you can skip the SA scanning until later. Just
set the value low enough that your system still runs ok so that
fetchmail can pull in the messages and feed them to exim. You want
that to happen as fast as possible (so you don't need to sit on the
line) and let exim store all the messages on the queue. Then, at your
system's leisure, let exim process the queue; which includes scanning
by SA.
| My Mailbox has 24 mb on it
Oh, that's a limiting factor too. spamd takes up about 8MB on its
own. It should share most (if not all) of that when it forks, but you
don't want more than 2 or maybe 3 spamd's running at a time. It does
hold the entire message in memory as it runs all the tests against it.
I bet that, as you have it, you're running into a memory shortage and
hitting swap a lot. By doing that you really slow down the system's
operation as it must wait on the (slow!, by comparison) disk for
memory accesses. Putting more memory in the system will likely give
you the biggest performance boost over any other upgrade you could
try. Unfortunately you probably need EDO RAM and that is more
expensive nowadays than SDRAM.
Use the -m option on spamd to limit how many children it will attempt
to spawn. I think exim also has an option to limit how many
(parallel) delivery processes it will run ... hmm, I only see
remote_max_parallel right now and that isn't going to help you.
HTH,
-D
--
The Consultant's Curse:
When the customer has beaten upon you long enough, give him
what he asks for, instead of what he needs. This is very strong
medicine, and is normally only required once.
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg06181/pgp00000.pgp
Description: PGP signature
