home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1204 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  1.7 KB
  1. Path: sparky!uunet!mitech!gjc
  2. From: gjc@mitech.com (George J. Carrette)
  3. Newsgroups: vmsnet.internals
  4. Subject: VMS tuning for a vaxcluster (LAVC)
  5. Message-ID: <2504@mitech.com>
  6. Date: 26 Aug 92 18:11:46 GMT
  7. Organization: Mitech Corporation, Concord MA
  8. Lines: 36
  9.  
  10. This talk about FPL etc has reminded me to ask a question
  11. about VAXCLUSTER (LAVC) behavior.
  12.  
  13. The behavior of the VMS memory management with respect to the FPL
  14. and installed images is said to reduce the amount of disk activity
  15. required when activating commonly used images, as long
  16. as the amount of free pages available allows pages from your favorite image
  17. to remain in the FPL.
  18.  
  19. Correct?
  20.  
  21. Now. My question is, what good does this do in a VAXCLUSTER environment,
  22. specifically a LAVC environment? Here a page fault consists
  23. of both a trip over the ethernet and a trip to disk.
  24.  
  25. Obviously if a satelite has the pages of an image already in memory,
  26. then you will winning big, avoiding a trip across the ethernet and everything.
  27.  
  28. But what about the trip to disk? Is there a way to avoid that?
  29.  
  30. The LAVC server node may have plenty of free memory, but it may have *never*
  31. activated any of the images that people on the LAVC's are interested in.
  32.  
  33. Even if it had activated those images, would there be any optimization
  34. available? (That is, does the vaxcluster lavc disk server -know- that
  35. pages from a disk file may already be available in memory?)
  36.  
  37. My current situation is that I have a VAXSTATION-3200 with plenty
  38. of free memory serving as a LAVC boot node, and I'm interested in
  39. any hacks available to speed things up. 
  40.  
  41. In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
  42. and SYS$SHARE also available on the local hard disk. That is a bit hackish,
  43. so I didn't bother re-doing that for VMS 5.5.
  44.  
  45. -gjc
  46.