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
