On 20/10/10 23:15, Roberto Suarez Soto wrote:
El dÃa Tue, 19 Oct 2010 21:24:29 +0000, Amos Jeffries<squid3@xxxxxxxxxxxxx>
escribÃa:
If its actually leaking its likely this:
http://www.squid-cache.org/Versions/v2/2.7/changesets/
The latest bug-fix snapshot of 2.7.STABLE9 is the best 2.7 to go with.
I'm afraid that didn't fix it. We're using latest 2.7.STABLE9 now
(retrieved on 20101014), and it's still happening. I also used
"memory_pools_limit 512 MB", but didn't help much.
But we've got a new lead: it seems that the iPhone 4 establishes
connections for very long (don't know how much, but who told me implied that
it could be days), and my guess is that it could make squid unable to reuse
the memory invested in those connections. So I'll try to set
"client_lifetime" to a conservative amount (one hour, several hours) and see
if that helps. Yes, I know it's a sketchy theory :-)
My next step would be to use "half_closed_clients on", but I'm afraid
that might break more things that it'd fix.
How much memory should squid spend when it has many opened
connections? In our case, I can see about 3000 connections to squid in
"ESTABLISHED" state, and they don't seem to go down. I've run calamaris
against one of the access.logs and it says that there are a lot of
"long" (i.e.,> 10e10 msec) connections. They are the ones that carry more
traffic. Would it make sense for squid to use a lot of memory to attend these
many long connections?
Not really, the longer requests come in two forms...
Persistent, which have many requests inside. These release resources
regularly between requests. Could be one of these leaking slowly.
Genuine long requests, these work with relatively big "window" buffers
(flexible capped around 64K) for the data in transit. These also tend to
be CONNECT tunnels which have a straight read->write pump with minimal
buffering. The others may consume cache_mem space for the large objects
storage for the duration.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.8
Beta testers wanted for 3.2.0.2
