home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sun / admin / 4840 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.7 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!usc!sdd.hp.com!uakari.primate.wisc.edu!relay!afterlife!dpkemp
  2. From: dpkemp@afterlife.ncsc.mil (David P. Kemp)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: Kernel config - pseudo-device win128 (and other stuff)
  5. Message-ID: <1992Jul21.130934.16098@afterlife.ncsc.mil>
  6. Date: 21 Jul 92 13:09:34 GMT
  7. References: <1992Jul15.232035.29008@kodak.kodak.com>
  8. Organization: The Great Beyond
  9. Lines: 52
  10.  
  11.  
  12. In article <1992Jul15.232035.29008@kodak.kodak.com> dennett@sunshine.Kodak.COM (Charlie Dennett) writes:
  13. >Our 4/490 server is a real workhorse.  It is the lab's main server,
  14. >has 18 disk spindles, server home directories and some other
  15. >filesystems for well over 100 users, and supports a half dozen
  16. >(and growing) X terminals.  Many of the users have Sparcstations
  17. >but this 4/490 is used for long running CPU and I/O intensive jobs.
  18. >We've investigating how to squeeze more performance out of it.  
  19. >We noticed that the kernel config file has an entry:
  20. >
  21. >    pseudo-device win128
  22. >
  23. >We were wondering if we had anything to gain by increasing the 128
  24. >to, say, 256?  Any ideas?  We already have maxusers set to 128.
  25. >
  26.  
  27. Not unless you have a Sunview user sitting at the 4/490 console with
  28. *lots* of windows open :-).  Since you are using X terminals, that's
  29. not very likely.
  30.  
  31. >
  32. >We've also used adb to increase the buffer cache to a max of 112
  33. >as recommended in the O'Reilly "System Performance Tuning" book and
  34. >some other papers we've read.  (Why is 112 the max?)
  35. >
  36. >Any other recommendations on squeezing more oomph out of this beast?
  37.  
  38. Tuning for performance doesn't necessarily mean "more of everything",
  39. although since you have 128 M, increasing the kernel size with 
  40. MAXUSERS can't hurt.
  41.  
  42. I would focus in a different direction though - try to offload the
  43. server by running the long CPU-bound jobs on your Sparcstations
  44. (you didn't say SS-1, 1+, or 2, but even the 1 is a reasonable
  45. compute engine compared to the 490).   Try to identify which of
  46. your jobs do lots of continuous disk I/O, and keep them on the
  47. server.  Jobs that do sequential reads from a large file, and
  48. not much writing are ideal candidates for migration to the Sparc-
  49. stations.
  50.  
  51. NFS and heavy computing just don't mix very well on an NFS server - 
  52. the nfsd's get starved no matter how many of them you use, and the
  53. clients get "server not responding" and "server OK" message pairs
  54. out the wazoo.
  55.  
  56. Your Sparcstations are "dataless", aren't they?  If they are diskless
  57. (root and swap on the server) you have to go out and buy them local
  58. disks *right now*, no matter how tight money is.
  59.  
  60. -- 
  61.    Dave Kemp   dpkemp@afterlife.ncsc.mil              "Pave the Bay!"
  62.    #include <std/disclaimer>
  63.