home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20155 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  4.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!gatech!usenet.ins.cwru.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: RE: Pagefile on DECram ramdisk - any comments?
  5. Message-ID: <9212311339.AA11687@uu3.psi.com>
  6. Date: 31 Dec 92 12:38:55 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 77
  11.  
  12.  
  13.     We are currently running a VAX 4000-300 with VMS 5.4-3.  We have 128Mb
  14.     of memory.  We currently only have one pagefile (50,000 blocks) and
  15.     yes, it's on the system disk (RF31).  Our other two disk drives
  16.     (RF72's) are currently being hit so hard that a secondary pagefile on
  17.     those disks is not possible.  I have proposed buying an RF35, but that
  18.     will not happen until the Fall of 1993.
  19.  
  20.     We currently have a lot of memory that is not being used (170,000+
  21.     blocks).  Working set sizes have been tuned so folks are getting the
  22.     memory they deserve.  I have been exploring the possibility of
  23.     installing a secondary pagefile on to a DECram ramdisk of say,
  24.     60,000-70,000 blocks.
  25.  
  26.     Has anyone ever done this before and if so, are there any issues that
  27.     I should be aware of?  If I make the pagefile on the ramdisk
  28.     sufficiently large so that it has the most Reservable pages available,
  29.     I should be able to ensure that the secondary pagefile is used more
  30.     often than not.  We're running DECram v1.0, and I'm getting ready to
  31.     install v1.1 this week.
  32.  
  33. Think about what you are proposing:  Pages go to the pagefile when there is
  34. no room for them (for whatever reason) in memory.  You propose to have them
  35. go to - well, memory, when there is no room in memory.
  36.  
  37. While this will work, it makes very little sense.  If, as you are currently
  38. configured, effectively all of your physical memory were in use most of the
  39. time, the effect of installing a ramdisk would be to make your run SHORT of
  40. memory, thus increasing paging.  And to what end?  The pages newly forced out
  41. of memory would actually stay in memory - but they'd be shuffled around from
  42. memory marked as "memory" to memory marked as "ramdisk", costing you CPU time.
  43.  
  44. Since your current configuration leaves a significant - in fact, huge! -
  45. amount of memory free, you can look for other ways to make use of it.  On a
  46. system-wide basis, you might consider decreasing FREELIM/FREEGOAL so as to
  47. encourage pages to stay on the look-aside lists, getting pretty much the same
  48. effect as "paging" them to a ramdisk for a LOT less overhead.  You might
  49. consider installing /RESIDENT your most commonly used images - both the VMS
  50. images and any 3rd-party or locally created, commonly-used images.
  51.  
  52. However, I suspect the real clue to what's going on here is in your claim that
  53. "Working set sizes have been tuned so folks are getting the memory they
  54. deserve".  When I hear a system manager talk about what users "deserve", it
  55. usually implies a rather, ahem, limited view of user/system management inter-
  56. action.  It sounds as if you are letting some arbitrary, probably decade-old
  57. notion of the "right" amount of memory get in the way of sound system manage-
  58. ment.
  59.  
  60. If your system HAS the memory, it's foolish not to let processes use it!  I'd
  61. STRONGLY suggest you first re-examine your policies and standards in this
  62. direction to see if they make any sense with the equipment and load you have
  63. TODAY - not whether they made sense when you had 50 people on an 11/780.
  64. Then set limits that will make effective use of your resources.  As a quick
  65. calculation:  Let M be your estimate - it doesn't have to be exact - of the
  66. maximum number of simultaneous active users your system has to deal with.  If
  67. you have some users who sit at a prompt for long periods of time, don't count
  68. them against M - or count them as a fraction of a user.  (Be generous with M;
  69. it's better to estimate somewhat too high than somewhat too low.)
  70.  
  71. Now let P be the number of pages on your system, not counting those reserved
  72. to VMS; again, this doesn't have to be exact.  Then P/(1.5*M) should be a
  73. reasonable value for the WSQUOTA of a typical user.  WSEXTENT should be
  74. considerably larger - as a first cut, I'd make it 4 times WSQUOTA.  (If you
  75. have distinctly different classes of users, you can of course vary these
  76. numbers a bit - though typically I'd no more than halve or triple WSQUOTA.
  77. You can be much more generous with WSEXTENT; there's essentially no reason NOT
  78. to be generous with it.)
  79.  
  80. Finally, make sure WSMAX is large enough - at least as large as the biggest
  81. WSEXTENT, ignoring any WSEXTENT's that you might set to "infinite" (i.e., let
  82. this user take all the memory he needs, when memory is available).  Also, if
  83. you've modified FREELIM/FREEGOAL, make sure BORROWLIM is set rationally so
  84. that the WSEXTENT values can contribute something.  AUTOGEN will do this for
  85. you.
  86.  
  87.                             -- Jerry
  88.  
  89.