Re: [squid-users] RE: Too Many Open File Descriptors

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 10 Aug 2011 15:46:36 +1200

 On Tue, 09 Aug 2011 23:07:05 -0400, Wilson Hernandez wrote:
> That used to happen to us and had to write a script to start squid
> like this:
>
> #!/bin/sh -e
> #
>
> echo "Starting squid..."
>
> ulimit -HSn 65536
> sleep 1
> /usr/local/squid/sbin/squid
>
> echo "Done......"
>
>

 Pretty much the only solution.

 ICAP raises the potential worst-case socket consumption per client
 request from 3 FD to 7. REQMOD also doubles the minimum resource
 consumption from 1 FD to 2.

 Amos

>
> On 8/9/2011 10:47 PM, Justin Lawler wrote:
>> Hi,
>>
>> We have two instances of squid (3.0.15) running on a solaris box.
>> Every so often (like many once every month) we get a load of below
>> errors:
>>
>> "2011/08/09 19:22:10| comm_open: socket failure: (24) Too many open
>> files"
>>
>> Sometimes it goes away of its own, sometimes squid crashes and
>> restarts.
>>
>> When it happens, generally happens on both instances of squid on the
>> same box.
>>
>> We have number open file descriptors set to 2048 - using squidclient
>> mrg:info:
>>
>> root_at_squid01# squidclient mgr:info | grep file
>> Maximum number of file descriptors: 2048
>> Largest file desc currently in use: 2041
>> Number of file desc currently in use: 1903
>> Available number of file descriptors: 138
>> Reserved number of file descriptors: 100
>> Store Disk files open: 68
>>
>> We're using squid as an ICAP client. Both squid instances point two
>> different ICAP servers, so it's unlikely a problem with the ICAP
>> server.
>>
>> Is this a known issue? As its going on for a long time (over 40
>> minutes continuously), it doesn't seem like it's just the traffic
>> spiking for a long period. Also, we're not seeing it on other boxes,
>> which are load balanced.
>>
>> Any pointers much appreciated.
>>
>> Regards,
>> Justin
>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>
Received on Wed Aug 10 2011 - 03:46:39 MDT

This archive was generated by hypermail 2.2.0 : Wed Aug 10 2011 - 12:00:01 MDT