home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / archives / admin / 521 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  3.6 KB

  1. Xref: sparky comp.archives.admin:521 comp.unix.admin:6922
  2. Path: sparky!uunet!enterpoop.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
  3. From: jik@athena.mit.edu (Jonathan I. Kamens)
  4. Newsgroups: comp.archives.admin,comp.unix.admin
  5. Subject: mail servers and sendmail -- disk space vs. speed vs. file table trade-offs
  6. Followup-To: comp.unix.admin
  7. Date: 6 Jan 1993 15:13:52 GMT
  8. Organization: Massachusetts Institute of Technology
  9. Lines: 58
  10. Distribution: world
  11. Message-ID: <1iesvgINN4l0@senator-bedfellow.MIT.EDU>
  12. NNTP-Posting-Host: pit-manager.mit.edu
  13.  
  14. I'm having a problem with the mail archive server on my workstation, and I'm
  15. hoping someone else may be able to suggest a solution to it, because I haven't
  16. been able to come up with one.
  17.  
  18. When someone sends a request to the server, it is placed into a queue directory
  19. for later processing.  Every ten minutes or so, cron runs the program that
  20. actually reads the queue files (each of which is just a mail message) and
  21. processes them, mailing responses to the requests in them.
  22.  
  23. The queue processor calls sendmail to deliver responses.  Sendmail can do
  24. delivery in three different modes:
  25.  
  26. 1) Asynchronous -- after parsing the message, it forks and the parent exits. 
  27. The child delivers the message, or queues it if it can't be delivered.
  28.  
  29. 2) Synchronous -- the message is parsed and delivered (or queued) by one
  30. process, and it doesn't exit until delivery or queuing takes place.
  31.  
  32. 3) Queuing -- the message is parsed and then immediately queued for later
  33. delivery.
  34.  
  35. I have been avoiding (3), because I don't want my disks to fill up if someone
  36. sends many requests to the server in a short period of time.
  37.  
  38. Until recently, I have been using (1).  However, I've discovered that it can
  39. potentially cause my workstation's file table to and cause all kinds of ugly
  40. failures as a result.   This occurs if someone with a slow, but functioning,
  41. SMTP server sends a large number of requests to the server.  By processing them
  42. all, the server starts up a large number of sendmail processes.  Since the SMTP
  43. server being contacted is up, but slow, all of the sendmail processes stay
  44. running for a long time doing the delivery.  If the SMTP server were simply
  45. down, they would immediately queue the messages after realing this, so it
  46. wouldn't be a problem.  Furthermore, if all of the sendmail processes trying to
  47. deliver caused the workstation's load to go up, then sendmail would notice the
  48. higher load and start queuing rather than trying to deliver, but this doesn't
  49. seem to occur, probably because the sendmail processes spend most of their time
  50. sleeping, waiting for responses from the remote SMTP server, and therefore
  51. don't up the load much.
  52.  
  53. So, if I don't want to fill my disks, and I don't want to fill my file table, I
  54. have to use (2), i.e., tell the mail server to try to deliver each message
  55. synchronously, not proceeding until it is either delivered or queued because it
  56. can't be delivered.  The problem with this is that it's slow.  Although most of
  57. the responses from the server can probably be delivered quickly, they end up
  58. waiting in line for delivery behind the few responses going to slow SMTP
  59. servers.
  60.  
  61. One solution to this problem would be to somehow get sendmail to check the
  62. number of slots left in the file table in addition to checking the load
  63. average, and to queue rather than trying to deliver if there aren't a lot of
  64. slots free.  As far as I can tell, standard Berkeley sendmail doesn't do that;
  65. is there a version that does?
  66.  
  67. If not, can anyone suggest another solution to this problem?
  68.  
  69. -- 
  70. Jonathan Kamens                                         jik@MIT.Edu
  71. Aktis, Inc.                                 Moderator, news.answers
  72.