home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / mail / mx / 753 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  4.2 KB

  1. Path: sparky!uunet!darwin.sura.net!mips!sdd.hp.com!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!mx-list
  2. From: "George D. Greenwade" <bed_gdg@SHSU.BITNET>
  3. Newsgroups: vmsnet.mail.mx
  4. Subject: RE: A question and an enhancement request.
  5. Message-ID: <0095E029.C20869E0.1045@SHSU.edu>
  6. Date: Thu, 23 Jul 1992 16:02:27 CDT
  7. Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 67
  10.  
  11. On Thu, 23 Jul 1992 08:56:24 EDT, Brian Tillman <tillman@swdev.si.com> posted:
  12. > John F. Sandhoff (sandhoff@csus.edu) writes:
  13. >
  14. > >My system is what I consider busy (typically over 1000 messages a day) and
  15. > >I don't recall seeing this problem. I seem to recall that ONCE I got
  16. > >a 'currently locked' error from FLQU SHOW but other than that I don't
  17. > >see locks. CPU speed may have a lot to do with it - MX runs on an 8820
  18. > >here (though sometimes at priority 1 - ouch!)
  19. >
  20. > Well, we use MX a *whole* lot less (about six people) and it's happened
  21. > twice in the past month.  Now, that may seem very little, but it seems that
  22. > if we release MX to all 500 of our accounts, we could very well see this
  23. > much more frequently. This would mark MX in the minds of the Email people
  24. > here as a flawed product and we would be forced to use our previous SMTP
  25. > mailer (yuck!).
  26.  
  27. I guess we're lucky -- in two-plus years of use, I've only seen or heard of
  28. this happening once (when MX 3.0 was still in beta), and we viewed it as a
  29. chance occurrence (I'm sure Ken or someone looked at it hard, but as I
  30. recall chance was the final verdict).  We are a busy site, I think -- we
  31. run 15 processes under MX on three nodes, our FILESERV handles over 300
  32. outbounds a day (it's been months since we've handled fewer than 200 in a
  33. day; last month we handled 16,871 files, not including the verification
  34. messages and error replies) and we have three quasi-active lists with over
  35. 100 subscribers, another with 300+ and still another with around 500 (which
  36. is probably the most active of all of our lists).  That's even before
  37. getting to our local users.  The MCP/FLQ count can easily go up
  38. 8,500-11,000 in a normal school day (yes, I know MX generates 2-4 per
  39. message, but that's still quite a few).
  40.  
  41. Hunter already shared our approach -- we don't allow MX to ever compress
  42. the file; instead, we shut it down each morning around 0100, then do the
  43. compression in a daily batch job (the SYSTEM_QUEUE.FLQ_CTL file generally
  44. goes from 7000+ blocks back down to <300 during this process).  Each of the
  45. 3 nodes has its own batch queue and its own restart file called by the main
  46. file, verifying JNET, doing things to help in the FILESERV directories,
  47. which are also our anonymous ftp directories, etc.  The main file even
  48. waits to see if SYSTEM_QUEUE is locked before it does its thing:
  49.  $loop:
  50.  $ open/read file SYSTEM_QUEUE.FLQ_CTL/error=not_yet
  51.  $ back/ign=int SYSTEM_QUEUE.FLQ_CTL.0 SYSTEM_QUEUE.FLQ_opt.0
  52.  $ OPT SYSTEM_QUEUE.FLQ_opt !OPT calls a command file to optimize the file
  53.  $ copy SYSTEM_QUEUE.FLQ_opt SYSTEM_QUEUE.FLQ_Ctl
  54.  $ close file
  55.  $not_yet:
  56.  $wait 00:00:10
  57.  $goto loop
  58. At 0100, with all processes down, this is relatively safe, and it allows
  59. all open processes to complete prior to doing anything.
  60.  
  61. > John, if you still use FLQU, then you must still be using V2.x.  Perhaps
  62. > this problem didn't exist in versions prior to V3.x (we're using V3.1C).
  63.  
  64. Huh????  The two tools give different information.  I commonly use FLQ to
  65. get a quick look at the queue, then take given numbers from it to MCP QUE
  66. SHO/ALL.  FLQ, at least in our environment, is far superior for a quick
  67. look; MCP QUEUE has better features -- you (or we) really need both.
  68.  
  69. Regards,   George
  70. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  71. George D. Greenwade, Ph.D.                            Bitnet:  BED_GDG@SHSU
  72. Department of Economics and Business Analysis         THEnet: SHSU::BED_GDG
  73. College of Business Administration                    Voice: (409) 294-1266
  74. P. O. Box 2118                                        FAX:   (409) 294-3612
  75. Sam Houston State University              Internet:        bed_gdg@SHSU.edu
  76. Huntsville, TX 77341                      bed_gdg%SHSU.decnet@relay.the.net
  77. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  78.