# RAM usage limits

Justin C Harris (jch1134@jackson.freenet.org)
Sat, 20 Apr 1996 23:16:18 PDT

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

    On Sat, 20 Apr 1996, Christopher Unkel wrote:

    > 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.
    > >

    First off, we could use Martian's built-in, proc_size() I think it was, and
    set up something like:

    while (1)
     size = proc_size();
     if (size > $server_options.max_ram_usage)
       [call a built-in or something to find the task, and kill it]
     endif
    endwhile

    > 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.

    Well, this protection would obviously be an option. *Most* ArchWizards should
    know enough about their system and the MOO to set the right setting to
    $server_options.max_ram_usage. If not, they will have to find someone that
    does, or just not use it.

    > 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.

    Exactly. The process size is what we'd be monitoring.

    >
    >
    > LambdaMOO will not be hacked into an idiot-proof,
    hostile-programmer-safe, > system.  It is simply not designed for it. >
    We'll (or at least I will) try to make it hostile-programmer-safe. Anyone
    that has put a lot of work into a MOO would want to do the same.

    re: using ps
     ps would be way to slow.

    					Justin