home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.sun.admin
- Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!bradley.bradley.edu!pwh
- From: pwh@bradley.bradley.edu (Pete Hartman)
- Subject: Re: Bringing a Sun to it's knees
- Message-ID: <1993Jan26.163308.14520@bradley.bradley.edu>
- Organization: Bradley University
- References: <T6AXBYAV@cc.swarthmore.edu> <1993Jan25.221022.28758@ra.msstate.edu>
- Distribution: usa
- Date: Tue, 26 Jan 93 16:33:08 GMT
- Lines: 22
-
- In <1993Jan25.221022.28758@ra.msstate.edu> fwp@CC.MsState.Edu (Frank Peters) writes:
- >If you look in /sys/conf.common/param.c you will see that MAXUPRC (the
- >number of processes per user) is set to 5 less than the total number of
- >processes available. Keeping in mind that the overwhelming number of
- >Suns are single user-at-a-time desktop workstations this makes sense.
- >You don't want a single user workstation holding back a bunch of
- >process slots for other users that aren't going to be there.
- >
- >You can prevent this, of course, by modifying param.c to set MAXUPRC to
- >something more conservative. Thats what we do on our multiuser
- >systems. Exactly what to set it to depends upon your usage patterns of
- >course.
-
- Of course, if you use up all the memory, you still get the same
- symptom, so even if you set MAXUPRC to nusers/2 or some such
- you run into the same problem if some program allocates memory
- out the wazoo.
-
- Any pointers to where I can limit MAXUMEM?
- --
- Pete Hartman Bradley University pwh@bradley.bradley.edu
- For every mad scientist who's had a convenient thunderstorm just on the night
- his Great Work is finished and lying on the slab, there have been dozens whove
- sat around aimlesly under the peaceful stars while Igor clocks up the overtime
-