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

Re: RAM usage limits



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