also sprach ino-waiting:
> > 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.
Just for reference, I've got a K6-2/333, 384MB RAM, SCSI drives, Linux w/
ext2fs.
> > 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.
This is silly. I've got our concurrencyremote set to 180 and the machine
just hums along. If it weren't also our primary nameserver and if it weren't
running apache, I might bump it up higher. Granted this isn't a 386 or
whatnot, but your statement of running 30 concurrent processes on a
pentium-class machine doesn't fly.
FYI, I've got another "throwaway" dual P90 EISA (!) machine with the
concurrency* set at 90. No problems whatsoever.
/pg
--
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]
