Re: [squid-users] running out of filedescriptors

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 27 Jan 2010 23:19:38 +1300

Landy Landy wrote:
> Hello.
>
> This morning we didn't have internet. Checked squid's cache.log and found:
>
> 2010/01/26 09:10:07| client_side.cc(2843) WARNING! Your cache is running out of filedescriptors
> 2010/01/26 09:10:23| client_side.cc(2843) WARNING! Your cache is running out of filedescriptors
> 2010/01/26 09:10:39| client_side.cc(2843) WARNING! Your cache is running out of filedescriptors
> 2010/01/26 09:10:55| client_side.cc(2843) WARNING! Your cache is running out of filedescriptors
> 2010/01/26 09:11:11| client_side.cc(2843) WARNING! Your cache is running out of filedescriptors
> 2010/01/26 09:11:24| clientNatLookup: NF getsockopt(SO_ORIGINAL_DST) failed: (2) No such file or directory

The others advice about file descriptors and ulimit is spot-on. So go
with that.

You have another issue which is causing problems though. The
SO_ORIGINAL_DST is caused by normal proxy HTTP traffic arriving at a
'transparent' intercept port. There is a lot of kernel and Squid
processing done uselessly for these requests. You are using 3128 for
interception.
  If its _is_ a real NAT failure on transparent traffic they will end up
with an error page and you have some serous issues with the NAT table
filling up to deal with.

The thing to know about transparent ports is that they should be private
between the in-box firewall doing NAT and Squid. No other software
should be able to send packets there. Squid can happily run 3128 as
normal, and another random port firewalled from general access for
gettging the NAT intercepted packets.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
   Current Beta Squid 3.1.0.15
Received on Wed Jan 27 2010 - 10:19:48 MST

This archive was generated by hypermail 2.2.0 : Wed Jan 27 2010 - 12:00:05 MST