home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / ultrix / 6896 < prev    next >
Encoding:
Text File  |  1992-09-14  |  2.6 KB  |  67 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
  3. From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  4. Subject: Re: kernel configuration recommendations?
  5. Message-ID: <1992Sep14.204930.13982@nntpd2.cxo.dec.com>
  6. Lines: 54
  7. Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  8. Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  9. Organization: Digital Equipment Corporation
  10. References:  <1992Sep11.185331.1@qucdnee.ee.queensu.ca>
  11. Date: Mon, 14 Sep 1992 20:49:30 GMT
  12.  
  13.  
  14. In article <1992Sep11.185331.1@qucdnee.ee.queensu.ca>, rick@qucdnee.ee.queensu.ca writes:
  15. >
  16. >i have a lab of two dozen decstation 5000/20s (12 meg, rz23l) with a
  17. >5000/240 (32 meg, 2 rz57s, ultrix 4.2a) as a server. all the clients 
  18. >page locally. are there any sensible changes to make to the server
  19. >kernel? (increasing bufcache comes immediately to mind - what are 
  20. >sensible values to start with?) if there's any general advice to be had 
  21. >i'd appreciate it a lot.
  22.  
  23. The two recommendations you have so far good ones:
  24.  
  25. 1.  (Yours) Increase the size of the buffer cache.
  26.  
  27. 2.  Set cache_bufcache.
  28.  
  29. For sizing the buffer cache, the best recommendation I can make is
  30. to use whatever is left over.  What you'd want to do is monitor the
  31. amount of memory used over some typical period of usage.  Based on
  32. this you can choose a size that will use most of what's available,
  33. but leave enough for typical short falls.  Non-typical short falls
  34. will still cause the server to page, but if they happen very often
  35. they aren't "non-typical" and you re-adjust the size of the cache.
  36.  
  37. Monitor is good for this sort of performance monitoring and has
  38. an example report filter included that looks at the memory usage.
  39. The compress Monitor tar(5) archive is on:
  40.  
  41.     gatekeeper.dec.com:/pub/DEC/monitor.tar.Z
  42.  
  43. The other thing to watch is disk I/O.  If one disk is getting all
  44. of the work, you might want to think about rearrange the file systems
  45. to spread the I/O load out over the two.  If you don't have Prestoserve
  46. on the server, it will help a lot to improve write performance from the
  47. clients back to the server.
  48.  
  49. The last part is the hardest, but if you can identify the typical
  50. file sizes being transfered and find that they are large, the I/O
  51. enhancement support in V4.3 may be helpful, once you have the server
  52. file systems setup reasonably.
  53.  
  54. >
  55. >thanks
  56.  
  57. You're welcome.
  58.  
  59. >
  60. >rp
  61. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  62. >Rick Pim                                            bitnet:rick@qucdnee
  63. >
  64. --
  65. Alan Rollow                alan@nabeth.cxo.dec.com
  66.  
  67.