At 6:37 AM -0700 9/25/03, Howard Shere imposed structure on a stream of electrons, yielding:
SIMS has been great for a long time. Our mail volume keeps increasing (and
our spam volume and virus volume keeps increasing)

We have about 7000 mail accounts on our server.

I've said it before, and I'll repeat it: you are pushing SIMS past where I believe it is a viable solution. By an order of magnitude. I admire your persistence, but I think you would make your life easier with something like Postfix or CGP.


We have POP allowing 250 connections at a time.

We have SMTP allowing 100 incoming and 250 outgoing. If we set the incoming
higher, the server gets swamped and can't deliver mail fast enough.

It would be nice to have 2 SMTP settings to allow our users (client hosts)
to send mail even when we are limiting the flow of mail coming in from the
outside. We can do this with another box, but so far we have not.

You should.


When our server gets to about 3,000 messages in the queue it can no longer
keep up and falls further and further behind. When there are more than 6,000
messages in the queue SIMS can become unstable (or, at least, unresponsive)
and our auto restart thingy restarts the machine.

This is running on a Blue & White 300Mhz G3 with a PCI scsi 2940 and a
fairly fast 18gb drive (which normally has about 3gb free).

So, I have several questions:

Can anyone guess if this is a cpu, disk or network problem? The drive light
is not on solid.

It's cpu, but disk is involved. HFS (even HFS+) simply cannot deal efficiently with very large directories. 3000 files in the Queue folder makes every new change to that directory (i.e. new messages arriving or messages being delivered) take a very long time, and the structure of HFS means that those changes must always be serialized. The result is that you have a single-file line of tiny transactions with the disk that are each connected to a significant amount of computational work which gets greater with every new file in the Queue folder. Not a lot of real disk action, but all of the cpu time is devoted to figuring out exactly what needs to be written to disk.


We have several T1s and although this machine can fill 2 of
them with outgoing traffic, the incoming traffic does not nearly fill the
T1s. The finder on the machine is sluggish when this is going on, but it is
still useable. We can open the large queue folder and see the number of
items in it, but it takes time. We usually keep this folder (and the
accounts folder) closed in the finder.

Good. The Finder has even worse problems with big folders than HFS has underneath it, and causes poor performance for other processes trying to work with folders that it has open.


It is possible that the disk is fragmented, but since the files are mostly
small I am not sure.

Anyone have any suggestions aside from: buy a G4 or G5....

No, just get a second G3 and split your inbound and outbound mail. You can do this most effectively by fully splitting them, but that carries with it an issue of authentication for outbound mail relay which MAY be a troublesome issue. The lesser approach would be to keep the first outbound hop for users on the same machine where their accounts live, but have it send all mail by way of a second machine that does nothing but handle the outbound mail. That will take the load of delivery to the world off the machine trying to deliver to mailboxes and essentially split your queue into fast-delivery (inbound mail and the initial hop of outbound mail) on one machine and slow delivery on that outbound machine trying to talk to the world at large.


Do you have any sense of what the inbound/outbound ratio is, particularly when you have an overloaded queue?


-- Bill Cole [EMAIL PROTECTED]


############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>



Reply via email to