Re: [squid-users] 3.2.5 comm_open: socket failure: (24) Too many open files

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Sat, 29 Dec 2012 23:56:10 +0200

I am using the trunk version and didn't check any other version and I
don't think that there was a change about limits checks or way of
handling in squid for a long time.

The ulimits are tricky in some systems due to system policies.
What linux distro are you using?

Eliezer

On 29/12/2012 23:24, 叶雨飞 wrote:
> Is this a new patch or is it in 3.2.5? I've never seen anything less
> than 16384 in the log file, even though I've run into the issue in
> 3.2.5
>
> On Sat, Dec 29, 2012 at 1:19 PM, Eliezer Croitoru <eliezer_at_ngtech.co.il> wrote:
>> I made sure and squid logs the current available FD from the OS and not just
>> using compiled options.
>>
>> 2012/12/29 23:16:18 kid1| With 8192 file descriptors available
>>
>>
>> Eliezer
>>
>> On 29/12/2012 22:41, 叶雨飞 wrote:
>>>
>>> So you are saying even squid is configured to use 16384 fd, it
>>> couldn't because limit is 1024?
>>>
>>> That's kind of confusing, I tried to use ulimit -n 16384 as root to
>>> raise FD limit now, will report back.
>>>
>>> Maybe squid can probe at start and warn about mis-matching fd limits?
>>>
>>> On Sat, Dec 29, 2012 at 12:16 PM, Eliezer Croitoru <eliezer_at_ngtech.co.il>
>>> wrote:
>>>>
>>>> Hey,
>>>>
>>>> It's probably the linux ulimit settings.
>>>> run:
>>>> ulimit -Sn
>>>> ulimit -Hn
>>>>
>>>> If there is a limit of 1k in the list you will need to change it since
>>>> squid
>>>> bound to the OS limits.
>>>>
>>>> Regards,
>>>> Eliezer
>>>>
>>>>
>>>>
>>>> On 29/12/2012 14:30, 叶雨飞 wrote:
>>>>>
>>>>>
>>>>> Squid is configured with 16384 FD and it is only using 1k, it seems it
>>>>> is still complains about running out of FD. Is there a regression from
>>>>> 3.2.5 -》 3.2.2 ?
>>>>>
>>>>> 2012/12/29 04:25:53 kid1| Reserved FD adjusted from 100 to 15391 due to
>>>>> failures
>>>>> 2012/12/29 04:25:53 kid1| comm_open: socket failure: (24) Too many open
>>>>> files
>>>>> 2012/12/29 04:25:53 kid1| comm_open: socket failure: (24) Too many open
>>>>> files
>>>>> 2012/12/29 04:25:53 kid1| comm_open: socket failure: (24) Too many open
>>>>> files
>>>>> 2012/12/29 04:25:53 kid1| comm_open: socket failure: (24) Too many open
>>>>> files
>>>>> 2012/12/29 04:25:53 kid1| WARNING! Your cache is running out of
>>>>> filedescriptors
>>>>>
>>>>>
>>>>>
>>>>> # squidclient -p 9444 mgr:info
>>>>> HTTP/1.1 200 OK
>>>>> Server: squid/3.2.5
>>>>> Mime-Version: 1.0
>>>>> Date: Sat, 29 Dec 2012 12:28:37 GMT
>>>>> Content-Type: text/plain
>>>>> Expires: Sat, 29 Dec 2012 12:28:37 GMT
>>>>> Last-Modified: Sat, 29 Dec 2012 12:28:37 GMT
>>>>> X-Cache: MISS from oow-ssh
>>>>> X-Cache-Lookup: MISS from oow-ssh:9444
>>>>> Connection: close
>>>>>
>>>>> Squid Object Cache: Version 3.2.5
>>>>> Start Time: Sat, 29 Dec 2012 12:24:37 GMT
>>>>> Current Time: Sat, 29 Dec 2012 12:28:37 GMT
>>>>> Connection information for squid:
>>>>> Number of clients accessing cache: 0
>>>>> Number of HTTP requests received: 4257
>>>>> Number of ICP messages received: 0
>>>>> Number of ICP messages sent: 0
>>>>> Number of queued ICP replies: 0
>>>>> Number of HTCP messages received: 0
>>>>> Number of HTCP messages sent: 0
>>>>> Request failure ratio: 0.00
>>>>> Average HTTP requests per minute since start: 1064.1
>>>>> Average ICP messages per minute since start: 0.0
>>>>> Select loop called: 1196966 times, 0.201 ms avg
>>>>> Cache information for squid:
>>>>> Hits as % of all requests: 5min: 0.5%, 60min: 0.5%
>>>>> Hits as % of bytes sent: 5min: 0.2%, 60min: 0.2%
>>>>> Memory hits as % of hit requests: 5min: 23.8%, 60min:
>>>>> 23.8%
>>>>> Disk hits as % of hit requests: 5min: 0.0%, 60min: 0.0%
>>>>> Storage Swap size: 0 KB
>>>>> Storage Swap capacity: 0.0% used, 0.0% free
>>>>> Storage Mem size: 32512 KB
>>>>> Storage Mem capacity: 99.2% used, 0.8% free
>>>>> Mean Object Size: 0.00 KB
>>>>> Requests given to unlinkd: 0
>>>>> Median Service Times (seconds) 5 min 60 min:
>>>>> HTTP Requests (All): 0.13498 0.13498
>>>>> Cache Misses: 0.13498 0.13498
>>>>> Cache Hits: 0.00000 0.00000
>>>>> Near Hits: 0.07409 0.07409
>>>>> Not-Modified Replies: 0.00000 0.00000
>>>>> DNS Lookups: 0.02683 0.02683
>>>>> ICP Queries: 0.00000 0.00000
>>>>> Resource usage for squid:
>>>>> UP Time: 240.038 seconds
>>>>> CPU Time: 21.460 seconds
>>>>> CPU Usage: 8.94%
>>>>> CPU Usage, 5 minute avg: 8.94%
>>>>> CPU Usage, 60 minute avg: 8.94%
>>>>> Process Data Segment Size via sbrk(): 111960 KB
>>>>> Maximum Resident Size: 457216 KB
>>>>> Page faults with physical i/o: 0
>>>>> Memory usage for squid via mallinfo():
>>>>> Total space in arena: 112092 KB
>>>>> Ordinary blocks: 105455 KB 1075 blks
>>>>> Small blocks: 0 KB 0 blks
>>>>> Holding blocks: 17236 KB 6 blks
>>>>> Free Small blocks: 0 KB
>>>>> Free Ordinary blocks: 6637 KB
>>>>> Total in use: 6637 KB 5%
>>>>> Total free: 6637 KB 5%
>>>>> Total size: 129328 KB
>>>>> Memory accounted for:
>>>>> Total accounted: 41168 KB 32%
>>>>> memPool accounted: 41168 KB 32%
>>>>> memPool unaccounted: 88160 KB 68%
>>>>> memPoolAlloc calls: 9
>>>>> memPoolFree calls: 964366
>>>>> File descriptor usage for squid:
>>>>> Maximum number of file descriptors: 16384
>>>>> Largest file desc currently in use: 991
>>>>> Number of file desc currently in use: 611
>>>>> Files queued for open: 0
>>>>> Available number of file descriptors: 15773
>>>>> Reserved number of file descriptors: 15391
>>>>> Store Disk files open: 0
>>>>> Internal Data Structures:
>>>>> 1969 StoreEntries
>>>>> 1969 StoreEntries with MemObjects
>>>>> 1956 Hot Object Cache Items
>>>>> 0 on-disk objects
>>>>>
>>>>
>>>> --
>>>> Eliezer Croitoru
>>>> https://www1.ngtech.co.il
>>>> sip:ngtech_at_sip2sip.info
>>>> IT consulting for Nonprofit organizations
>>>> eliezer <at> ngtech.co.il
>>
>>
>> --
>> Eliezer Croitoru
>> https://www1.ngtech.co.il
>> sip:ngtech_at_sip2sip.info
>> IT consulting for Nonprofit organizations
>> eliezer <at> ngtech.co.il

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
sip:ngtech_at_sip2sip.info
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
Received on Sat Dec 29 2012 - 21:56:30 MST

This archive was generated by hypermail 2.2.0 : Sun Dec 30 2012 - 12:00:04 MST