# processor load problem - update

Ian Macintosh (ian@iman.internet.co.nz)
Mon, 13 Nov 1995 16:09:17 PST

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

    On Mon, 13 Nov 1995, Andreas Dieberger wrote:

    > Thanks for the replies I got so far. Here is an update on the situation and
    > some previously missing info:
    >
    > The server we are running is 1.7.8p4  with the MPLpatch 1.4.
    >
    > It certainly was not a good idea to run the MOO under root and with that
    > high priorities - that was an accident it seems. Still that alone doesnt
    > explain why an empty moo needs that many cycles on the server.

    You probably have a faulty verb, as some other posts mention.  However,
    while you're tracking it down, here's a little change that will make you
    more popular with your sysadmin.

    If you are using the 'restart' script that is supplied with LambdaMOO by
    Pavel, edit the following line:

    nohup ./moo $1.db $1.db.new $2 >>& $1.log &

    to read:

    nohup nice +19 ./moo $1.db $1.db.new $2 >>& $1.log &

    That will ensure that your moo only get's CPU cycles that are about to be
    lost/wasted anyway.  (Not 100% true, but as close as you get :^)

    Here's a verb I just wrote to test it out, and the result on the system:

    @verb me:test

    .program me:test
    while (1)
      suspend(0);
    endwhile
    .

    Which ended up causing this.
    --------------------
     12:55pm  up  1:02,  7 users,  load average: 1.05, 1.05, 0.81
    35 processes: 32 sleeping, 2 running, 1 zombie, 0 stopped
    CPU states: 58.6% user, 39.3% system, 95.3% nice,  2.3% idle
    Mem:  15048K av, 13928K used,  1120K free,  8172K shrd,  3724K buff
    Swap: 20804K av,     0K used, 20804K free

      PID USER     PRI  NI SIZE  RES SHRD STAT %CPU %MEM  TIME COMMAND
      250 moo       19  14 1244 1584  356 R N  90.5 10.5 20:11 moo mud.db
       64 root      25  10  100  320  344 R N   4.8  2.1  2:58 /usr/bin/top
    ------------------

    I couldn't notice any difference in the system's response when I did this
    either, and I'm only running a 486DX-33 with Linux.  Even loging in to the
    moo went smoothly, and unless I looked at the 'top' display, I would have no
    indication that a runaway verb was in progress.

    Most people on the list would probably benefit by doing so as well, as the
    moo would generally be the lowest priority task on the system in the view of
    the sysadmin, and to have the task reflect that view would be appropriate.
    I'm quite sure that even Lambda wouldn't notice the difference if that was
    done to the system.

    You can fiddle the priority while the task is alive if you want, by logging
    on as root, and using the 'r' option of 'top'.  That way you'll be able to
    verify that what I say is true without restarting the moo.

    You can renice the task without logging on as root, but will not be able to
    increase the priority again unless you do log on as root.

    	Ian.