On Thu, Aug 12, 1999, Fred Lindberg <[EMAIL PROTECTED]> wrote:
>
> Thanks for your input. The limiting factor for my redhat linux 2.2.5
> installation was a per user process limit of 256. The reason I
> sometimes got 256 or 257 concurrency is that reporting is not exactly
> synchronous with forking.
>
> Thus, in addition to increasing the number of file handles, you need to
> rebuild the kernel after editing:
>
> /usr/src/linux/include/linux/tasks.h NR_TASKS from 512 to e.g. 2048.
> Per-user limit defined to half this on the line below.
>
> There also appears to be a bug that limits the number of per process
> file handles to 1024. There are "unofficial" patches for this, but
> AFAIK, not integrated into the official kernel.
Many shipping linux kernels come with "big-fd" patches as well. For
instance, the SuSE 6.2 kernel is 2.2.10 with a "big-fd" patch applied.
You also need to increase NR_OPEN in linux/tasks.h as well.
> If anyone has more insight into this, I'd love to hear it. With the
> patch, our P100/64MB does very well at a concurrencyremote of 400.
> Since performance was limited by concurrency (many slow/dead clients)
> we got considerably better throughput.
I wrote the patch to get a concurrencyremote of 1000. This is on a
P500/512MB so it's a bit different, but like I've mentioned in previous
emails, qmail-remote is so lightweight that practically no memory is
used and we rarely hit 0.10 load. This box will be doing more soon, but
this is a good test for us.
JE
