# Task RAM-usage limits...

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

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

    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-