> Vincent Danen:
> What would be a good average value for the silent concurrency limit and is
> there a better way to figure it out on a system-by-system basis? Or
note that the concurrency-limit for either local or remote delivery
actually means the number of processes running concurrently to deliver
mail, synchronized by qmail with fifos. each process gets it's own memory
map with it's own stack and process control structures, and in most systems
identical program invocations get to run their own copy of the program
text. i don't think it makes sense to let more than 20 copies of qmail-
spawn|local|remote run at a time, unless you count your ram-megabytes by
the hundred and have more than one cpu on a very fast bus. take my trusty
'386/8/162: if any two processes are in the run queue, i can go out,
get addicted to heroin and come back to repair what's left of my family
just to watch my shell prompt again. and, even more seriously, if the
computer yuo want to install qmail on is an old leftover with not much to
do any more, you should not let it run more than 10 processes. at least,
that's what my machine can handle.
> should I just leave it at 120 or "hard-code" a different limit (ie. should
> I make it 150 or 160 or what would be appropriate for a Linux system
> running on a pentium class or higher machine?).
pentium: good. ext2fs: slow if many files are in a directory, which is
the typical situation for a mail server. no more then 30.
--
clemens [EMAIL PROTECTED]
do D4685B884894C483
