From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.archives.admin,comp.unix.admin
Subject: mail servers and sendmail -- disk space vs. speed vs. file table trade-offs
Followup-To: comp.unix.admin
Date: 6 Jan 1993 15:13:52 GMT
Organization: Massachusetts Institute of Technology
Distribution: world
NNTP-Posting-Host: pit-manager.mit.edu

I'm having a problem with the mail archive server on my workstation, and I'm
hoping someone else may be able to suggest a solution to it, because I haven't
been able to come up with one.

When someone sends a request to the server, it is placed into a queue directory
for later processing.  Every ten minutes or so, cron runs the program that
actually reads the queue files (each of which is just a mail message) and
processes them, mailing responses to the requests in them.

The queue processor calls sendmail to deliver responses.  Sendmail can do
delivery in three different modes:

1) Asynchronous -- after parsing the message, it forks and the parent exits. 
The child delivers the message, or queues it if it can't be delivered.

2) Synchronous -- the message is parsed and delivered (or queued) by one
process, and it doesn't exit until delivery or queuing takes place.

3) Queuing -- the message is parsed and then immediately queued for later
delivery.

I have been avoiding (3), because I don't want my disks to fill up if someone
sends many requests to the server in a short period of time.

Until recently, I have been using (1).  However, I've discovered that it can
potentially cause my workstation's file table to and cause all kinds of ugly
failures as a result.   This occurs if someone with a slow, but functioning,
SMTP server sends a large number of requests to the server.  By processing them
all, the server starts up a large number of sendmail processes.  Since the SMTP
server being contacted is up, but slow, all of the sendmail processes stay
running for a long time doing the delivery.  If the SMTP server were simply
down, they would immediately queue the messages after realing this, so it
wouldn't be a problem.  Furthermore, if all of the sendmail processes trying to
deliver caused the workstation's load to go up, then sendmail would notice the
higher load and start queuing rather than trying to deliver, but this doesn't
seem to occur, probably because the sendmail processes spend most of their time
sleeping, waiting for responses from the remote SMTP server, and therefore
don't up the load much.

So, if I don't want to fill my disks, and I don't want to fill my file table, I
have to use (2), i.e., tell the mail server to try to deliver each message
synchronously, not proceeding until it is either delivered or queued because it
can't be delivered.  The problem with this is that it's slow.  Although most of
the responses from the server can probably be delivered quickly, they end up
waiting in line for delivery behind the few responses going to slow SMTP
servers.

One solution to this problem would be to somehow get sendmail to check the
number of slots left in the file table in addition to checking the load
average, and to queue rather than trying to deliver if there aren't a lot of
slots free.  As far as I can tell, standard Berkeley sendmail doesn't do that;
is there a version that does?

If not, can anyone suggest another solution to this problem?

-- 
Jonathan Kamens                                         jik@MIT.Edu
Aktis, Inc.                                 Moderator, news.answers
Newsgroups: comp.archives.admin