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

Re: RAM usage limits

On Sat, 20 Apr 1996, Justin C Harris wrote:

> How would it be laggy? All it would be doing is basically comparing two
> numbers, to see if there was a huge difference. e.g. The next server
> maintainer could add a mem_check() function, which would return the
> amount of memory the MOO is using (btw, that would be a great function
> to have, even if it's not used for this purpose), then add a 4th process,
> that compares these numbers, and maybe even have it check in options.h 
> whether a person wants this task running. It should be a fairly small one.

The reason that it would possibly be slow wouldn't be comparing the
number, but getting the number.  The most likely way to detect a change in
process size would be to call sbrk(0), which returns the address of the
end of the data segment; when a process grows, the address this returns
increases.  Doing a bit of testing, though, I don't think that this would
cause performance problems, depending on how sbrk(0) is implemented.  (A
DECstation 3100, not the powerhouse of the world, handled 40000 calls to
sbrk per second, whereas an HP 9000/715 handle around a million.) So I'd
guess that this wouldn't be likely to put a big speed dent in the server,
even if it was called a *lot*. 

But, this idea has its difficulties.

First of all, figuring out whan an appropriate maximum value for a process
size increase during a task isn't a piece of cake.  It depends on how much
memory and swap the machine has, how close to capacity it is, what's
expected based on the database, how efficient the memory manager is, etc. 
Choosing an appropriate value would require a fair amount of technical
knowledge, and it would be very hard to find a default that would work
reasonably well for all systems. 

It still doesn't protect the system against all malicious attacks (though it 
probably helps stop some accidents.)
Consider this code (assume #100 is the programmer and #101 is an object 
owned by the programmer):

pinfo = {#100, ""};
pnum = 0;
while (1)
  pnum = pnum+1;
  fork (0)
    pname = tostr(pnum);
    add_property(#101, pname, {}, pinfo);
    while (ticks_left() > 200 && seconds_left() > 1)
      #101.(pname)={#101.(pname), "ack"};
    endwhile
  endfork
  suspend(1);
endwhile

Running this code under WinMOO for one minute (on a Pentium/100) I
produced a 2.7 meg object.  (And note that the code is potentially wasting
a bit of time; running out of ticks usually takes less than a second. 
With a minor code change I got 4 megs in a minute.) Not amazingly fast,
but fast enough.  The properties it generates are less than 50K apiece;
they won't trigger a memory-increase-per-task limit or possibly a
max-prop-size limit, nor does it ever tick-out or second-out. Note also
that it produces an increase in *db* size as well as process size, which
people seem to be ignoring. 


LambdaMOO will not be hacked into an idiot-proof, hostile-programmer-safe,
system.  It is simply not designed for it.


[Minor addendum relating to implementation of memory-use increase limits:

A fourth process is not the way to go about implementing this.  First of
all, it's frequently all but impossible for one process to find out about
the memory usage/process size of another.  (Yes, ps can do it.  But ps
does it by deciphering the process table, and notice that it needs to be
set-uid root or set-gid kmem or similarly privileged.  It's not so fast,
either--think about how long a ps takes even on a fast machine.  It's not
instantaneous, and for something that would happen as often as this would,
that's means it's slow.) Second, there's no guarantee that the process
will execute at all when we really want it to.  If a task is suddenly
making the machine swap because of sudden huge memory usage, it may not be
executing our task-checking process.  Finally, the process would have to
communicate with the server process when the limit is exceeded--and fast. 
The reliable way to do this is a signal, but we're already using all of
them.]


  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/
Follow-Ups: References:
Home | Subject Index | Thread Index