Re: MAXMEMB

On Wed, Jan 08, 2003 at 03:11:48PM -0500, cfowler wrote:
> Is there a technical reason that MAXMEMB's is limited to 16?  I've
> changed mine to 96.

the big reason (and a main reason for multiple processes) is the
maximum number of open files a process can have.  each console can have
a few file descriptors associated with it (device, logfile, connected
users, and socket).  so, off the top of my head that would be ( 2 *
consoles + users + 1 ).

you also have the speed of your conserver host vs the rates at which
data could be streaming to it.  go back a decade and this was probably
more of an issue than today, but it's still something to think about.

and then you have the problem recently mentioned about delays.  if any
of the 96 console connections "lock up", it'll delay all activity on
the 96 consoles.  with 16, there's less of an impact (but, obviously
there is an impact, based on the outstanding question of the delays).
this can be an issue once the server comes up or during startup - with
16 per process you get a bit of parallelization during startup.

so, is there any reason not to up the number to 96?  no.  assuming you
know the risks and weigh things appropriately.  if i remember right,
i've upped the number to 48 at some sites.  but that was mainly to
reduce the memory footprint in older versions of the code which had
staticly allocated buffers.  no need to worry about that with the
current code.  personally, i wouldn't change from 16 unless there was a
really good reason (like wanting to only have one child process for
firewall rules or some such reason).

Bryan