Task RAM-usage limits...

H. Peter Anvin (hpa@trantor.zytor.com)
Sat, 20 Apr 1996 12:31:09 PDT


Followup to:  <Pine.SOL.3.91.960420093932.3975C-100000@pollux>
By author:    Fabien Ninoles <ninf01@gel.usherb.ca>
In newsgroup: local.moo
>
> IMHO, Panic is a worst thing for a server than simply killing a task li=
ke=20
> MOO... But, like Pavel wrote, limiting a tasks size in the MOO is a=20
> low-level feature that need to think about at the first steps in the=20
> developpement of the server.
> I'm not really expert in server developpement but I thing that the best=
=20
> way to avoid Panic is to isolate the task to the main server. Our own M=
UD=20
> runs on a client of the main server and are support by crontab job that=
's=20
> looking if the MUD runs and restart it if necessary. The cron itself is=
=20
> run on the main server and are completely isolate from the rest. I don'=
t=20
> know if that mesures preserve all the server from any panic cause by th=
e=20
> MUD, but they seem to work with most of the tasks that the server have =
to=20
> run (something like /* or programmation errors in the same way of this=20
> example...)
>=20

Note most Unices have a function called ulimit(), usually available as
"ulimit" (sh/bash/ksh/zsh) or "limit" (csh/tcsh) from the shell.  That
should take care of that; once the MOO hits it resource limit any
further malloc() (really, sbrk()) will fail, and the MOO server might
panic, but the system will not.

	-hpa

--=20
PGP public key available - finger hpa@zytor.com
"The earth is but one country, and mankind its citizens."  --  Bah=E1'u'l=
l=E1h
GE/CS 3.1 d- s-:- a- C++++ ULIS++++$ P+++ L++++>+++++ E++ W++ N++ o+ K
w--- O@ M V- PGP+ t+ 5++ X? R@ tv- b++ DI++++ D++(+) G e++ h- r-- y-