Re: [squid-users] "Reserved number of file descriptors" sudden increase

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 23 Oct 2012 16:21:07 +1300

On 23/10/2012 3:47 a.m., "RODRIGUEZ CEBERIO, Iņigo" wrote:
> Hello,
>
> I'm running squid 3.0.STABLE13 on a CentOS 5.2.

Please upgrade, your Squid is no longer suported. Current Squid release
is version 3.2.3.

> It works normally and suddenly it colapsed. In the cache.log appears messages telling run out of file descriptors. Using squidclient I can see a change of this parameter, "Reserved number of file descriptors", from 100 to 1424. Here it is the squidclient info about FD:
>
> File descriptor usage for squid:
> Maximum number of file descriptors: 4096
> Largest file desc currently in use: 3193
> Number of file desc currently in use: 2673
> Files queued for open: 0
> Available number of file descriptors: 1423
> Reserved number of file descriptors: 1424
> Store Disk files open: 1
>
> Why does that parameter rise from 100 to 1400 in just few seconds? What's going on? Any piece of advise?

1400 does not matter. The 2673 is more important - this is number of FD
currently open and in use.

It can raise in three situations:
  1) scanning the disk cache in a "DIRTY" scan to rebuild the index file
by file. Requires opening every file on disk and can consume hundreds of
FD at once for the one process.

  2) receiving lots of client traffic. Might be a normal peak in
traffic, a DoS, or a broken client hammering away repeating a request
(usually seen with auth rejecteions).

  3) a forwarding loop, where Squid is processing a request which
instructs it to connect to itself as upstream. This is best prevented by
configuring "via on".

Amos
Received on Tue Oct 23 2012 - 03:21:20 MDT

This archive was generated by hypermail 2.2.0 : Tue Oct 23 2012 - 12:00:04 MDT