Re: FD's again: ulimit shows 1024, but recompiled squid...

Hello Klaus, et. al.

On Thu, Nov 26, 1998 at 09:49:43AM +0100, Klaus-Peter.Neurohr@toshiba-teg.com wrote:
> Hello Squid Users,
>
[...]

> ...
> File descriptor usage for squid:
> Maximum number of file descriptors: 256
> Largest file desc currently in use: 44
> Number of file desc currently in use: 25
> Available number of file descriptors: 231
> Reserved number of file descriptors: 64
> Disk files open: 3
> ...
>
> I read the FAQ and the archived mailinglist up and down, but could not find
> any hint. Maybe someone has an
> idea what went wrong.
>
> Best regards
>
> KP

Once upon a time, before switching to Linux-based systems, I ran a squid
1.1.x on one of our RM systems running SINIX 5.4x (a SVR4 clone by SNI)
There I had a similar problem: During configure and compile everything
pointed to 1024 FDs, but during runtime Squid would never open more than
256 sockets. However, cachemgr insisted on having 1024, while your's
claims to have 256 only.

It turned out that the limitation to 256 actually usable FDs came from
some array index for _iob (or was it __iob) structures for FILE * pointers
that was a char instead of a short int. As a result, it was quite dangerous
simply upping the value of _NFILE.

So my guess is your OS has a similar limitation but it is detected better
in newer Squid releases. After all, when assuming 1024 FDs, squid reservers
100 for itself. With 256 it "only" reserves 64, which gives you 36 more for
servicing clients, as I understand it.

I hope this helps.

So long,
Martin

--
Martin Boening, MB3792    | EMail: mboen@sbs.de
SBS SCN 12, Otto-Hahn-Ring 6, D-81739 Muenchen (Perlach), Germany
Phone: +49 896 364 2904   FAX: +49 896 365 1031