RE: [squid-users] Squid 3.0 and Linux 2.6 kernel tweaks

> fre 2010-02-19 klockan 10:10 -0800 skrev Andy Litzinger:
>
> > For example, back in the Squid v 2.6 days with 2.2 or 2.4 linux
> kernels I see lots of recommendations for raising the file descriptor
> limits to 8192 or 16384. With the 2.6 kernel it seems the default
> kernel params (at least in RHEL5) far exceed the fd kernel tweaks
> people used for 2.2 or 2.4 kernels. It would seem adding the ulimit –
> HSn 8192 would actually be decreasing the file descriptor limits from
> the 2.6 kernel defaults.
>
> 2.6 kernel default ulimit is 1024.

We run with stock kernels from CentOS/RHEL so I guess I meant in those the kernel and shell fd limits are way higher.

>
> > Also, what is the default value for –with-filedescriptors that Squid
> 3.0 STABLE24 supports? I don’t see that in the output of ./compile –
> help
>
> On must systems the default is whatever the ulimit is set to when you
> run configure.

Great, thanks. Is there any way to confirm this on a compiled squid, or is it best practice to define the value upon compilation?

>
> > I’d be happy to add a wiki page addressing the following scalability
> topics if someone points me to the correct location.
> > - Checking/Increasing the ephemeral port range
>
> usually not needed unless you have many hundreds/s forwarded requests.
>
> > - Checking/increasing file descriptor limits
>
> Squid tells at startup what limit it is running under.

I'm not sure I understand what you mean here. How/where does squid get this value? And I suppose I should have said checking/increasing the kernel file descriptor limits (/proc/sys/fs/file-max) and the shell file descriptor limits (ulimit -n).

>
> > - Checking/decreasing TCP TIME_WAIT
>
> Usually not needed. Closely connected to the ephemeral port range issue
> mentioned above.

I understand that TIME_WAIT and ephemeral port increases are not usually needed, but I am concerned with the case of reverse proxying thousands of very short lived requests per second. I suppose it's likely for the service to die long before I exhaust available resources, but at least I'll know I won't be bottlenecking anything.

I appreciate your feedback! I do think it would be valuable for this type of qualified information to make it into the wiki somewhere. I'll look for the process to do so, but if you have any hints as to where this info should live I would love to hear them.

Cheers,
 Andy

Received on Fri Feb 19 2010 - 20:54:13 MST