home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19724 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.9 KB
  1. Path: sparky!uunet!europa.asd.contel.com!gatech!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!UH01.Colorado.EDU!DWING
  2. From: DWING@UH01.Colorado.EDU (Dan Wing)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Pagefile size and distribution guidelines desired
  5. Message-ID: <01GSM0EJFKIA003NZ9@VAXF.COLORADO.EDU>
  6. Date: 22 Dec 92 16:23:25 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 53
  11.  
  12. Don Roberts, dsroberts@beckman.com, writes:
  13.  
  14. >What guidelines do others use for determining the proper size for pagefiles?
  15.  
  16. I always shoot for at least 50% free during peak times.
  17.  
  18. >  As we don't have a defragmentor the problem we've run into in
  19. >the past is that if we make them too small we are not later able to make them
  20. >contiguous until we can do an image backup and restore (almost never
  21. >unfortunately).  
  22.  
  23. A defragger will not help you here - page files are always open, and thus
  24. cannot be defragged.
  25.  
  26. >Currently we have two 100,000 block page files each for our
  27. >6420 and 6520, and this is a tad small.  
  28.  
  29. "Small" can only be gauged by how much you're using, which is a function of 
  30. your users' working sets, how much memory they're trying to use, and how much 
  31. memory you have.  A 100,000 block page file could be a perfect size for a 
  32. 512Mb VAX model XX running 10-20 batch processes against a database.
  33.  
  34. I've heard the recommendation that deleting the EVL process, and re-creating 
  35. it, can help reduce problems when you start seeing 'page file fragemented' 
  36. messages on OPA0:.  This is because EVL purges its working set.  Haven't been 
  37. able to try this, though....
  38.  
  39. >Does it do any good to put multiple page files for one system on one disk?  
  40.  
  41. One big page file is better than multiple small page files on the same disk.  
  42. If the page files are actually spread across multiple disks, you can get some 
  43. load balancing.
  44.  
  45. >If we have multiple page files per
  46. >system on several disks, but those pagefiles are on the same disks as the
  47. >pagefiles for other systems, isn't that just as bad?
  48.  
  49. Well, only if the (two?) systems need to read/write a page at the same time!
  50. Usually, the most activity to your page files is when the modified pages get 
  51. written -- adjusting your MPW parameters can reduce the impact of modified page 
  52. writing.  But you're right -- if you put each system's page file(s) on separate 
  53. disks you'll probably get better overall throughput.  The best bet would be to 
  54. put the pagefiles on the quietest disks, no matter what else is on them; I 
  55. wouldn't expect that all the nodes in your cluster would need to read/write 
  56. pages at the same time.
  57.  
  58. Moving all your pagefiles off the system disk is beneficial, especially in a 
  59. cluster, because the system disk usually gets hit pretty hard, and doesn't need 
  60. the extra abuse caused by a pagefile on the same disk.
  61.  
  62. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
  63.  Systems Administrator, University Hospital, Denver
  64.  
  65.