Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!munnari!bruce!labtam!foster!cbp
From: cbp@foster.avid.OZ (Cameron Paine)
Newsgroups: news.sysadmin
Subject: Re: Outrageous amount of multiple forks
Summary: Could you not lower your process ceiling?
Message-ID: <158@foster.avid.OZ>
Date: 5 Dec 88 00:29:18 GMT
References: <22401@cornell.UUCP> <2210005@acf3.NYU.EDU> <382@ivucsb.UUCP> <5810@polyslo.CalPoly.EDU>
Organization: Avid Systems Pty Ltd, Australia
Lines: 34

In article <2210005@acf3.NYU.EDU> rosenblg@acf3.NYU.EDU (Gary J. Rosenblum)
tells us about dorks who write endlessly forking programs.

In article <382@ivucsb.UUCP> news@ivucsb.UUCP (Todd Day) asks if there is a way
this can be prevented.

In article <5810@polyslo.CalPoly.EDU>, steve@polyslo.CalPoly.EDU
(Steve DeJarnett) suggests placing limits on individual CPU usage. He (rightly)
points out that this may unfairly restrict users doing real work.

When I went to school, there was a quota system in place designed to prevent
just this sort of malefaction (it prevented disk hogging too) on BSD systems.
Regretably, I've no idea where the software came from.

In the commercial world (under SV and its derivatives), I achieve this effect
by careful tuning of the MAXPROC and MAXUP parameters. The former establishes a
ceiling on total concurrent processes; the latter does the same on a per-user
basis.

On all the machines we manage, MAXUP falls in the range 20 - 30 and MAXPROC is
determined by:

	MAXPROC = MAXUP * available_login_ports + number_of_system_processes;

These two parameters are given different names by different kernels. They are
usually set in config.h (though many vendors provide cute front-ends to avoid
editing this file).

cbp
-- 

cbp@foster.avid.oz - {ACS,CS}net
cbp%foster.oz.au@uunet.uu.net - ARPAnet
...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.oz.au!cbp - UUCP
D