unfortunately, the forks are much fastr than cycles available for the
daemon to detect the hog. The process doing the fork may be a very small
one (say, setting up a long pipe in background or cron, for instance). The
largest process might be vi - hence the process causing the problem won't stop.
>
>Of course, something like a memd might be a substantial performance hit
>also.
>
>How do other unix oess handle this one?
The ones I've used use a global resource allocation accounting -
Each user is given an initial collection of resources (processes may
be limited to 50, virtual memory limited to 150MB,...) on login. As
resources are used they are subtracted from both the global maximums
and from the users maximums.
When the result goes to zero (say the global went to zero) then the
requesting process is aborted - insufficient global memory AND syslog
gets the message as a "critical - global resource xx depletion detected" level.
If the users maximum is zeroed then the process is aborted - insufficient
memory quota AND syslog gets the message as a "warning - user exceeded xx
quota".
If the global limit is below the users quota, then the user is not allowed
to complete login - insufficient global resources.
These can also be treated using a "minimum available" to a "maximum allowed"
usage. This would allow the user to login with the minimum (assuming the
resources for "maximum allowed" will be available later).
This way the user quotas can be configured to support a pre-determined
number of simultaneous users. Quotas can be set for a per/user or per/process
if the accounting implementation supports it. The description above is
focused on per/user accounting. per/process accounting can be a subset
of the per/user by initially dividing the quotas by the number of processes.
As more user processes appear, then each process must be smaller (virtual
memory space for this... cpu time doesn't apply, disk space doesn't apply).
To detect cpu hogs is more problematical - one way uses a scale factor
that is added to the users priority. For each idle interval the priority
is raised (until the maximum user priority is reached). Each time the
job recieves cpu time, its priority is lowered (until the users mimimum
is reached). I/O activity can be used to boost the users priority since
most processes wait during I/O and scheduling is idled. This causes
CPU bound processes to become more like background processes. Interactive
processes stay more active since they tend to do more I/O.
This type of cpu scheduling was done under VMS and seemed to work quite well.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/