home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1219 < prev    next >
Encoding:
Text File  |  1992-08-29  |  4.1 KB  |  103 lines
  1. Newsgroups: vmsnet.internals
  2. Path: sparky!uunet!decwrl!pa.dec.com!ripple.enet.dec.com!pettigrew_mi
  3. From: pettigrew_mi@ripple.enet.dec.com (Mike Pettigrew)
  4. Subject: Re: RE: VMS tuning for a vaxcluster (LAVC)
  5. Message-ID: <1992Aug29.013855.12775@PA.dec.com>
  6. Sender: news@PA.dec.com (News)
  7. Organization: Digital Equipment Corporation
  8. References:   <9208281916.AA02286@sndsu1.sinet.slb.com>
  9. Date: 28 AUG 92 17:53:34 PDT
  10. Lines: 91
  11.  
  12.  
  13. In article <9208281916.AA02286@sndsu1.sinet.slb.com>,
  14.  <brydon@dsny25.sinet.slb.com> writes...
  15.  
  16. > 
  17. >Okay, but what about the situation of one satellite vaxstation on a lightly
  18. >loaded network?  I think page read I/O's should be considered separately from
  19. >page write I/O's.  Does this satellite system do page read I/O's any faster
  20. >over the ethernet versus to local disk?  
  21. >
  22.  
  23. Paging I/O takes longer from a server over the ethernet than it does from
  24. a local disk.  There is not an easy way to separately measure page read and
  25. page write I/O times, nor any obvious reason why they should be greatly 
  26. different.  No one has yet noticed if this is so, though it is certainly
  27. possible.
  28.  
  29.  
  30. A satellite system that is paging any processes always seems to run slower
  31. with a server page file than with a local page file, even when the net is
  32. lightly loaded.  You can measure the difference in a very straightforward
  33. manner.
  34.  
  35. It is easy to measure program run time with a server page file and then
  36. again with a local page file.  It is somwhat difficult to make sure other
  37. conditions remain constant, but when you do, the answers are consistent.
  38.  
  39.  
  40.  
  41. > 
  42. >>What does have a very critical effect is changes to the system parameters
  43. >>WSMAX, MPW_HILIMIT, PQL_MWSQUOTA, PQL_MWSEXTENT , and also changes to the
  44. >>SYSUAF field WSEXTENT.  On a memory-rich system, these fields can be raised
  45. >>to much higher values than the default calculations.
  46. > 
  47. >Hmmmm well agreed, it's like money.  If you have more you can spend more.  In
  48. >my opinion Autogen does a good enough job of this except of course for
  49. >WSEXTENT and perhaps PQL_MWSEXTENT.
  50. > 
  51. >>The practical effect of raising these parameters is to eliminate paging
  52. >>and swapping activity on the sattelite nodes althogether.
  53. >>
  54. >>If you INSTALL all of the images that you are using on the sattelite nodes,
  55. >>and keep a free list of about 4,000 pages, you will rapidly have all of
  56. >>the relavent system image pages cached in the free list at the sattelite
  57. >>node.
  58. > 
  59. >This sounds a bit like the old DEC sales pitch of "buy more memory".  Indeed
  60. >it will improve matters, but that wasn't really the question being raised.
  61. > 
  62.  
  63.   Two questions were asked:
  64.  
  65.    (1)  Do page reads work faster from a server than from a local disk
  66.         if data blocks are cached?
  67.  
  68.         No, because you cannot cache the data blocks on the page file.
  69.         The local page file is always faster, and measurably so, given
  70.         equal disk drive speeds.
  71.  
  72.         If your application must page or swap, a local disk gives the
  73.         best performance.
  74.  
  75.  
  76.    (2)  Can you cache system routine pages on the server and thus improve
  77.         performance of a sattelite node?
  78.  
  79.         No, because the system routine pages are cached on the free
  80.         memory list of the sattelite node.
  81.  
  82.         You get best application performance by having "enough" memory
  83.         to run it with minimal paging, and by tuning VMS to use all of
  84.         that memory.
  85.  
  86. Some experiments indicate that you can do quite well in LAVC performance
  87. improvements, without buying a single piece of additional hardware, by
  88. a few simple VMS tuning changes.
  89.  
  90.  
  91. Not that I would ever discourage you from buying more DEC hardware! :)
  92.  
  93. ----------------------------------------------------------------------------
  94. | -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
  95. |                        (206) 661-3032
  96. |                        Digital Equipment Corporation 
  97. |                        Federal Way, Washington, USA
  98. |___________________________________________________________________________
  99. |  Surprises Every Day!
  100. |___________________________________________________________________________
  101. |These opinions are mine and not necessarily my employer's
  102. ----------------------------------------------------------------------------
  103.