home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.sun.admin
- Path: sparky!uunet!inmos!inmos.co.uk!brwal!hughm
- From: hughm@brwal.inmos.co.uk (Hugh McIntyre)
- Subject: Re: Bringing a Sun to it's knees
- Message-ID: <1993Jan26.180320.1880@inmos.co.uk>
- Sender: news@inmos.co.uk
- Organization: INMOS Limited, Bristol, UK
- References: <T6AXBYAV@cc.swarthmore.edu> <1993Jan25.221022.28758@ra.msstate.edu>
- Date: Tue, 26 Jan 1993 18:03:20 GMT
- Lines: 23
-
- In article <1993Jan25.221022.28758@ra.msstate.edu>, fwp@CC.MsState.Edu (Frank Peters) writes:
- |> In article <T6AXBYAV@cc.swarthmore.edu> eoliver@ralph.cs.haverford.edu (Erik Oliver) says:
- |> [stuff deleted]
- |>
- |> 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.
-
- Since (on this machine at least) there are at least 20 daemon processes owned by
- root any normal user is unlikely to ever get to 5 processes less than the total
- limit. You probably want a smaller limit.
-
- |> 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.
-
-
- Hugh McIntyre.
- INMOS, Bristol, UK.
-