home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / sysmgt / 413 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.2 KB
  1. Xref: sparky vmsnet.sysmgt:413 comp.os.vms:19701
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  3. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  4. Newsgroups: vmsnet.sysmgt,comp.os.vms
  5. Subject: Re: Pagefile size and distribution guidelines desired
  6. Date: 22 Dec 1992 06:18:46 GMT
  7. Organization: HST Wide Field/Planetary Camera
  8. Lines: 55
  9. Distribution: world
  10. Message-ID: <1h6c06INN9ks@gap.caltech.edu>
  11. References: <1992Dec21.092049.1074@beckman.com>
  12. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  13. NNTP-Posting-Host: sol1.gps.caltech.edu
  14.  
  15. In article <1992Dec21.092049.1074@beckman.com>, dsroberts@beckman.com writes:
  16. >We managed to work out getting a pair of two two gigabyte disks to replace two
  17. >ra92's for our set of "system" packs.  By system packs, in this case, I mean
  18. >where we put the layered products, page files, etc.  As opposed to user data
  19. >:-).  So, for the first time in a while, we can make our page files bigger. 
  20. >And contiguous.  WHat guidelines do others use for determining the proper size
  21. >for pagefiles?
  22.  
  23. Try to make your pagefiles big enough that they're never more than 2/3 used.
  24. Or, if you're willing to trust DEC, simply do an AUTOGEN with feedback.
  25.  
  26. >As we don't have a defragmentor the problem we've run into in
  27. >the past is that if we make them too small we are not later able to make them
  28. >contiguous until we can do an image backup and restore (almost never
  29. >unfortunately).
  30.  
  31. AUTOGEN will tell you how bit it thinks the files should be.  If it can't
  32. create them, you need to do a BACKUP/RESTORE.
  33.  
  34. >Currently we have two 100,000 block page files each for our 
  35. >6420 and 6520, and this is a tad small.
  36.  
  37. Well, based on what you've told us, how were we to know?  You might be running
  38. a system with only one user who only runs stuff he's ported from a CP/M system
  39. with 64K memory.
  40.  
  41. THE NECESSARY SIZE OF THE PAGEFILES DEPENDS ON HOW MANY USERS YOU'VE GOT AND
  42. HOW LARGE THEIR APPLICATIONS ARE!
  43.  
  44. Geez!  I'd've thought that would've been obvious!
  45.  
  46. Use AUTOGEN!
  47.  
  48. >Another thing I've never seen 
  49. >guidelines on is number of page files.  Does it do any good to put multiple 
  50. >page files for one system on one disk?
  51.  
  52. Obviously not.  All you achieve that way is to fragment your pagefile!
  53.  
  54. >If we have multiple page files per 
  55. >system on several disks, but those pagefiles are on the same disks as the 
  56. >pagefiles for other systems, isn't that just as bad?
  57.  
  58. No.  For each system, you should have at most one page file on each disk. 
  59. Optimally, you should only have page files on local disks.  Once you've got
  60. page files on non-local disks, optimal placement is *HIGHLY* dependent on the
  61. characteristics of your particular cluster.
  62. --------------------------------------------------------------------------------
  63. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  64.  
  65. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  66. understanding of astronomy is purely at the amateur level (or below).  So
  67. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  68. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  69. hold me responsible for it, but my organization had nothing to do with it.
  70.