home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sun / admin / 4862 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.4 KB  |  86 lines

  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!trd.sdata.no!halvard
  3. From: halvard@trd.sdata.no (Halvard Halvorsen)
  4. Subject: Re: Kernel Config -- Can maxusers be too big?
  5. Message-ID: <1992Jul22.143012.28974@ugle.unit.no>
  6. Sender: news@ugle.unit.no (NetNews Administrator)
  7. Organization: Skrivervik Data A/S
  8. References: <1992Jul19.160905.11322@kodak.kodak.com> <14emaeINNd8b@early-bird.think.com>
  9. Date: Wed, 22 Jul 92 14:30:12 GMT
  10. Lines: 74
  11.  
  12. from the 4.1.2 release manuals - chapter 8.3 :
  13.  
  14. maximum MAXUSERS values :
  15.  
  16. arch    mem<64mb    128mb        640mb        2.5gb
  17.  
  18. sun4    225        225        NA        NA
  19. sun4c    225        225        NA        NA
  20. sun4m    185        180        155        45
  21.  
  22. well it clearly says MAXUSERS <= 225 for sun4 - so you are clearly running
  23. an 'unsupported configuration' ...
  24.  
  25.  
  26.  
  27.  
  28. In article <14emaeINNd8b@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
  29. |> In article <1992Jul19.160905.11322@kodak.kodak.com> dennett@sunshine.Kodak.COM (Charlie Dennett) writes:
  30. |> >Can the maxusers parameter in the kernel config file be so big that
  31. |> >performance is affected?  Now, I have seen it where it was too big
  32. |> >and the kernel would not boot because there was not enough memory.
  33. |> >However, assuming memory is sufficient, can a large maxusers actually
  34. |> >hurt performnce?
  35. |> 
  36. |> Most (all?) of the tables whose sizes are derived from maxusers are wired
  37. |> in memory.  Therefore, this memory is not available for use as paging
  38. |> space.  If you increase maxusers enough that the working set often doesn't
  39. |> fit in memory, you'll page more.  This will slow the system down (how much
  40. |> depends on the difference between the working set and available memory).
  41. |> 
  42. |> >  (the target of my attack is a 4/490 running 4.1.1 with
  43. |> >128 meg of memory.  It is a major server --  18 spindles and 16+ gig --
  44. |> >for both disks and cpu cycles and also supports a half dozen or so
  45. |> >Xterminals.  Maxusers was at 128.  I tried raising it to 256.  It booted
  46. |> >fine.  Pstat -T told be the max number of files was perposterous at
  47. |> >over 14000.  What does pstat consider non perposterous?  It's running
  48. |> >at 256 now.  We'll see what happens when the users start wailing on it
  49. |> >Monday.)
  50. |> 
  51. |> Pstat considers nproc or nfiles more than 10,000 to be preposterous.  I
  52. |> don't think it's intended to be a judgement about your configuration
  53. |> decisions, but a sanity check; unexpectedly large values could be the
  54. |> result of /vmunix not being the kernel you booted, so it's looking in the
  55. |> wrong place for the value.
  56. |> 
  57. |> >Side issue:  As you may be able to tell by this posting and a couple
  58. |> >of my previous ones, in case you noticed, I am trying to teach myself
  59. |> >and to understand performance issues.  Is this group a reasonable
  60. |> >place to discuss performance issues and tuning?  If not, what would
  61. |> >be an appropriate place?
  62. |> 
  63. |> This is probably a good place, as would be comp.unix.large.  Also, there
  64. |> are some good books, such as "System Performance Tuning" by Mike Loukides,
  65. |> published by O'Reilly & Associates (they have lots of other good books for
  66. |> Unix users and administrators).
  67. |> -- 
  68. |> Barry Margolin
  69. |> System Manager, Thinking Machines Corp.
  70. |> 
  71. |> barmar@think.com          {uunet,harvard}!think!barmar
  72.  
  73. -- 
  74.  
  75.     0         halvard halvorsen - systems consultant - Skrivervik Data A/S
  76.   \/|/\    email      : halvard@trd.sdata.no
  77.     |      telephone    : + 47 7 59 23 74
  78.    / \/\   fax          : + 47 7 59 23 30
  79.  \/ ___________________________________________________________________
  80.  
  81.  
  82.  
  83.       
  84.  
  85.  
  86.