home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.archives.admin:521 comp.unix.admin:6922
- Path: sparky!uunet!enterpoop.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
- 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
- Lines: 58
- Distribution: world
- Message-ID: <1iesvgINN4l0@senator-bedfellow.MIT.EDU>
- 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
-