MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: processor load problem - update

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.
Follow-Ups: References:
Home | Subject Index | Thread Index