[Prev][Next][Index][Thread]

# Re: RAM usage limits

- Date: Sat, 20 Apr 1996 19:44:08 PDT
- From:
- cc: Bartmoss <bartmoss@mistral.co.uk>, moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <Pine.A32.3.91.960420184620.12275A-100000@erc.jscc.cc.tn.us>

    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:

- Re: RAM usage limits

- From: Justin C Harris <jch1134@jackson.freenet.org>

References:

- Re: RAM usage limits

- From: Justin C Harris <jch1134@jackson.freenet.org>

- Prev: Re: RAM usage limits
- Next: Re: RAM usage limits
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index