Re: Possible memory leak.

I think I can build a squid rpm with valgrind support for this purpose
and others.

Well now we have a bug report for the issue and it's good that we can
test it.
Note that this server has 99% hits since it is serving less then 30 file
which about half of them should be downloaded as a TCP_MEM_HIT.
Using StoreID stripping from the URL any traces of query parameters
redirecting squid to fetch the same object for all the request which are
abusing the "url path query" part to avoid caching.
(why would anyone that is testing his bandwidth against a specific
server would want to not fetch it from ram instead of spinning disks?)

Eliezer

On 07/11/2014 06:32 AM, Amos Jeffries wrote:
> This may be what Martin Sperl is reporting in the squid-users thread
> "squid: Memory utilization higher than expected since moving from 3.3 to
> 3.4 and Vary: working"
>
> What I'm trying to get from him there is a series of mgr:mem reports
> over time to see if any particular object type is growing unusually. And
> mgr:filedescriptors in case its a side effect of the hung connections
> Christos identified recently.
>
> If we are lucky enough that the squid was built with valgrind support
> there should be a valgrind leak trace available in one of the info and
> mem reports. This will only catch real leaks though, not ref-counting
> holding things active.
>
> Amos
>
Received on Fri Jul 11 2014 - 06:11:19 MDT