Article View: comp.archives.admin
Article #202mail servers and sendmail -- disk space vs. speed vs. file table trade-offs
From: Jonathan I. Kamens
Date: Wed, 06 Jan 1993 15:13
Date: Wed, 06 Jan 1993 15:13
58 lines
3713 bytes
3713 bytes
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
Technical Details
Message-ID:
<1iesvgINN4l0@senator-bedfellow.MIT.EDU>Path:
arc1-ca.pugleaf.net!sparky!uunet!enterpoop.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jikShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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