Returning User With Filesystem/Memory Tuning Questions

[Mel]

On Thursday 04 December 2008 04:12:04 Giorgos Keramidas wrote:
> On Wed, 3 Dec 2008 17:24:48 -0600 (CST), Kevin Monceaux 
<Kevin at RawFedDogs.net> wrote:
> > On Wed, 3 Dec 2008, Roland Smith wrote:
> >> Application crashed can also be due to bad hardware, especially
> >> memory. Make sure that you rule out hardware troubles before diving
> >> into the software.
> >
> > I don't think it was hardware related, but it's a possibility.
> >
> > Jogging my memory a bit more I think the first program I had memory
> > allocation problems was tin.  Fetching headers from even a semi-large
> > newsgroup would cause tin to crash.  I forget the exact error messages
> > but they were something along the lines of not being able to allocate
> > the needed amount of memory.  At the times of the failures there
> > appeared to be available RAM with swap space completely untouched.  The
> > errors occurred at about the same point in fetching the headers each
> > time. After much Googling I tried adjusting the following:
> >
> > kern.maxdsiz
> > kern.dfldsiz
> > kern.maxssiz
>
> Hi Kevin,
>
> The `kern.maxdsiz' tunable is a boot-time option that limits the amount
> of memory a _single_ process can allocate for its `data'.

And the dfldsiz is the initial soft limit. You can set dlfdsiz to 512 and 
maxdsiz to 1024, then all processes will initially bonk out at 512 and you'd 
have to use limit(1) to start up the process that needs more. 1024 will be 
the hard limit, nothing can excess beyond that.

Datasize is simplified malloc(3) where ssiz = stack size. Function pointers 
and local variables that are not malloced (char foo[1024]), are put there 
till stack is exhausted.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.