home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vms / 17697 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.8 KB
  1. Xref: sparky comp.os.vms:17697 vmsnet.mail.misc:92
  2. Path: sparky!uunet!verifone!jimmy_t
  3. From: jimmy_t@verifone.com
  4. Newsgroups: comp.os.vms,vmsnet.mail.misc
  5. Subject: Re: How to make VMSMail run lots faster
  6. Message-ID: <1992Nov9.160445.4632@verifone.com>
  7. Date: 9 Nov 92 16:04:45 -1000
  8. References: <1992Nov6.190229.4628@verifone.com>
  9. Organization: VeriFone Inc., Honolulu HI
  10. Lines: 45
  11.  
  12. Nick Abbot asked me to post the folowing:
  13.  
  14. In article <1992Nov6.190229.4628@verifone.com>, jimmy_t@verifone.com writes:
  15. > We are having severe VMS Mail performance problems.  The problems center around
  16. > users with lots (thousands) of mail messages stored as external files in the
  17. > VMS directory where they receive mail.  Once the size of this (or any) VMS
  18. > directory  passes 128 blocks or so (many of ours are >> 1000 blocks),
  19. > performance for adding new files begins a rapid decline.  Other users sending
  20. > mail to these accounts will  encounter seemingly random long delays waiting for
  21. > the "MAIL>" prompt after sending.
  22. > 
  23.  
  24.     "Making VAX Mail Fly".  Would that be, "VAX Air-Mail"...Hmmm?
  25.  
  26.     It seems to me, that you have a similar problem that Pathworks for VMS has.
  27. Lots of files.  One of our clients bought a 3100-90 for a file server.  The
  28. problem is the PCFS_SERVER's inability to cache directory info.  I suspect this
  29. is where your DIO's are being spent.  I've implemented a MASSIVE increase in
  30. the VMS ACP sysgen params that cache this on all drives mounted/system, it's a
  31. shared cache.  ACP_DINX*, ACP_DIR* and ACP_HDR*, the results were staggering,
  32. NO delays with the C:\> DIR /S.  Some Wordperfect(dos) functions that do
  33. directory searches, hauled donkey.  MONITOR FILE...was pegged at 100% hit rate.
  34. Really, really zippy.
  35.  
  36.     Keep in mind these params come out of paged pool, so for every page of
  37. increase, bump up PAGEDYN by number of bytes.  Also bump up the system working
  38. set by the same number of pages...SYSMWCNT.  That will prevent system page
  39. faults.  I'll be the first to admit that not all performance issues can be
  40. solved by throwing memory at them, but this one was obvious to the most casual
  41. observer, and I had a few lingering about at the time.
  42.  
  43.     In the case of the file server.  I had to reduce the memory for the
  44. PCFS_SERVER process to make room, I originally gave it the WORLD.  The end
  45. result was well worth it.  Usually there was a pregnant pause while doing a
  46. directory of a file service with hundreds of files in it.  That pause went
  47. away.
  48.  
  49.     On a side note.  You might want to BAC/IM these drives, and INIT them
  50. with the /HEADERS=<very big>, ie. double the size of INDEXF.SYS now.  This will
  51. give your INDEXF.SYS the room to grow and not "fall apart" later.  Then BAC/IM
  52. to restore, using the /NOINIT qualifier to preserve the newly allocated size of
  53. INDEXF.SYS.  DIR/SIZ=ALL.
  54.  
  55. Nick Abbot 70303.1354@compuserve.com
  56.  
  57.