RE: [squid-users] Too many open files

> Amos:
> Squid starts with 16K of which 100 are reserved FD. When it changes that
the 16K limit is still the total, but the reserved is raised to make N
sockets reserved/unavailable.
> So 16384 - 15394 = 990 FD safe to use after adjustments caused by the
error.

>> Peter:
>> I would have deduced that
>> there was some internal limit of 100 (not 1000) FD's, and that squid
>> was re-adjusting to the maximum currently allowed (16K)?

> Amos:
> Yes, that is correct. However it is the "reserved" limit being raised.
> Reserved is the number of FD which are configured as available but
determined to be unusable. For example this can be though of as the cordon
on a danger zone for FD - if Squid strays into using
> those number of sockets again it can expect errors. Raising that count
reduces Squid operational FD resources by the amount raised.
> Squid may still try to use some of them under peak load conditions, but
will do so only if there is no other way to free up the safe in-use FD.
> Due to that case for emergency usage, when Squid sets the reserved limit
it does not set it exactly on the FD number which got error'd. It sets is
2-3% into the "safe" FD count. So rounding 990 up that > slight amount we
get the 1024 which is a highly suspicious value.

I have managed to raise the per-process limit from 16K to 64K, and this is
reflected in the mgr:info statistics. However, if I understand your login
above, this is unlikely to be of benefit - I have to find where Ubuntu is
setting some limit of 1024? Am I correct? Is this a socket limit, rather
than a generic file descriptor limit?
Received on Sun Jul 28 2013 - 11:30:18 MDT