# processor load problem

Jay Carlson (nop@k2.ccs.neu.edu)
Sat, 11 Nov 1995 14:39:18 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > Andreas Dieberger writes:
    > > Our sysop told me that my MOO frequently takes up to 90% of the processor
    > > time of our server (which is a quite fast machine).
    > >
    > > And here is the info I got from out sysop:
    > >
    > > >  PID USERNAME PRI NICE   SIZE    RES STATE   TIME   WCPU    CPU COMMAND
    > > >  802 root     -25    0  6716K   596K cpu  1159:12 94.71% 93.88% mpl-moo
    > > >
    > > >As you can tell mpl-moo is taking 90% and up all the time and I'm not sure
    > > >why. If you could take another look at it I'd appreciate it. Thanks!
    > >
    > > I just noticed that the MOO obviously runs under root - I dont think that
    > > should be like that. Could that somehow cause the problem ...? Still how
    > > can it cause that much load if it doesnt *do* anything?

    > It looks to me like you're using a hacked MOO server, possibly with the MPL
    > patch (multi-port listening)?  In any case, something is weird about how you're
    > doing things, since the normal MOO server never runs as root

    More accurately, the MOO server doesn't muck with the UID it runs as;
    root is treated the same as any other user.

    This may not be optimal for MPL-patched servers; you'd sorta like the
    server to start as root, lock down port 80 (or whatever) and then
    throw away root privs.

    > and never mucks
    > with its scheduling priority.

    The kernel is perfectly happy to muck with its scheduling priority
    for you.

    >From man 1 ps under SunOS 4.1.4:

         PRI         Process  priority  (non-positive  when  in  non-
                     interruptible wait).
         NI          Process scheduling increment (see getpriority(2)
                     and nice(3V)).

    and man 1 nice:

         nice executes command with the nice value number.  The  nice
         value  is one of the factors used by the kernel to determine
         a  process's  scheduling  priority.   Scheduling  priorities
         range  from  0  to 127.  The higher the value, the lower the
         command's scheduling priority, and the lower the value,  the
         higher  the  command's  scheduling priority.  In addition to
         the nice value, the kernel also recent CPU usage by the pro-
         cess,  the  time  the  process  has been waiting to run, and
         other factors to arrive at scheduling priority.

    ...so what's probably happening here is that an unrenice'd MOO server
    is chewing all the CPU, and the kernel is giving it a lower priority
    in order to give interactive tasks an edge.

    > What's the rest of the story?

    The rest of the story is that something weird *is* happening.  It's
    quite possible that MPL has a bug; I'm sure that Ivan or someone else
    would appreciate a chance to debug this.  JHM, another MPL-patched
    server has never exhibited this behavior, though.

    My best guess is that you have a connection that's locked in
    I-don't-understand-that mode.  We had this problem at one of MITRE's
    servers, and it was eventually tracked down to a hosed client that
    sent a bad line (like "telnet> "), to which the MOO server said "I
    don't understand that.", which then triggered another line from the
    client....

    Whenever you have non-human network connections in 1.7.8 and earlier,
    you have to be very careful not to let the input stream get out of
    control.  The simplest thing to do is make sure you have a read()
    loop locked on the connection at all times.  Orbitnet gets a bit
    fancier, and puts both connection objects into rooms that have :huh
    verbs that can't escalate the I-don't-understand-that condition.

    > 	Pavel

    Jay Carlson
    nop@io.com    nop@ccs.neu.edu    nop@kagoona.mitre.org

    Flat text is just *never* what you want.   ---stephen p spackman