MOO-cows Mailing List Archive
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 &
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:
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.
Subject Index |