:On the shell servers I run, we've got 200-300 users running tasks.
:Occasionally, through intent or misconfiguration, a user either forkbombs,
:or gets a large number of processes running sucking lots of cpu.
:I'd like to see an option that makes all the processes run by one uid have
:the same weight as one process another uid is running.
:i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
:1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
:40 processes get 50% cpu shared between them. 
:This way, one errant user can't have as significant of an impact.
:Is this plausable?

    Plausable, yes.  Useful:  probably not as useful as you might think.  I
    wouldn't even consider doing something like that for BEST, it could lead
    to cascade failures.

    For example, if a user is running procmail or cron on a relatively loaded
    system, the user's share of the cpu relative to other users might not be
    sufficient to handle the user's medium term mail and/or job load.  If there
    are a few hundred users logged in, this could rapidly devolve into a
    cascade failure which fills the system's process table.  This in turn can
    lockup sendmail's waiting to lock the user's mailbox which in turn can 
    lead to a cascade failure with the root-run sendmails.

    Sometimes, the most noble of purposes can make a machine less stable in
    inobvious ways.  In the above example, limitations on a user process might
    lead to a backup of root-run services.

    A user-run CGI is another example.  Say you have a web server which runs
    CGI's under a user id.  If the web site is loaded down and the user happens
    to run a log processing script, execs of the user's CGIs might slow down
    due to the load balancing 'feature'.  The web server may now wind up in the
    situation where it is forking CGIs faster then it can retire them.  Leading
    to another cascade failure.

    In general, it is best to treat process scheduling without taking into
    account other processes run by the same user.  

    If a user misbehaves, the best solution is to stomp on him until he does
    behave, not try to shove the misbehavior under the run by making the system
    'control' the user's resources.  If you do not actively control the 
    behavior of your users all you will accomplish is to have a large number of
    them misbehaving continuously rather then just one or two.  The result
    is going to be the same:  A loaded down server and lots of complaints.
                                        Matthew Dillon 

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to