Re: FD leak, except, not really

On Fri, 12 Jun 1998, Eric Stern wrote:

> I noticed this strange thing happening to my squid1.2beta22 recently.
>
> File descriptor usage for squid:
> Maximum number of file descriptors: 3000
> Largest file desc currently in use: 1007
> Number of file desc currently in use: 116
> Available number of file descriptors: 2884
> Reserved number of file descriptors: 100
>
> The # in use is staying pretty stable, but the "Largest file desc
> currently in use" keeps going up, like it is not reusing FD #'s. It will
> keep going up until it reaches the max, then squid will jump the reserverd
> number way up, and things stop working, requiring a restart.
>
> Has anyone else seen this happening? This *might* not be squids fault,
> since the 3000 FD's patch to the linux kernel didn't go exactly smoothly
> (2.0.34). I thought I got it all patched up right but I may have blown it.

There's a new 3000 fd patch for linux-2.0.34 at http://www.linux.org.za/patches
Or you can try http://roadrunner.swansea.uk.linux.org/2.0.35-3kfd, which
is an older patch with some tweaking to make it patched on 2.0.34. You may
check your patch with this one to see if you have blown something.. :)

BTW, the patch at www.linux.org.za claim to fix bug that prevent > 341
fd's to be selected at once and it also make NR_OPEN and NR_TASKS
configurable through make config. I'm using it for week without any
problem (yet.. :)

Oskar, do you know maximum number that I can safely use to config NR_OPEN
and NR_TASKS?

--
aet