On 27/09/2012 7:38 p.m., tcr@xxxxxxxxxxxx wrote:
Still no valgrind-appended info appended to the mgr:mem.
Hmm. Okay. I have confirmed that that cache mgr report is where teh details are supposed t appear. There is valgrind memory report dumped under the header "Valgrind report:".
There are two conditions: 1) Squid is built using valgrind headers and --with-valgrind. 2) some macro called "RUNNING_ON_VALGRIND" is true.
Here is an earlier one, and a later one showing growth: http://bit.ly/QxXL3f http://bit.ly/PqRJ1s This is on one of the lower-utilization servers and I'm currently running squid under valgrind which is slowing it down further, so the growth won't be as fast as it is on some other servers. But if everything behaves as it always has, the process will grow and grow. Right now after about 8 hours of runtime it's using about 700MB resident. Tomorrow morning that will be more.
If we can get the valgrind details appearing we don't have to wait for much growth at all. Every single unique leak will show up, just with the worst ones having growing repeated leak counters.
mgr:mem shows heavy allocations around these: Short Strings HttpHeaderEntry acl_ip_data Here's info that might be relevant: The way I'm doing access is to manage the allowed IPs acl file via an external program, and then reload squid via init.d (just sending a HUP) when it changes. I know this probably isn't optimal and I should use an external ACL, but perhaps my sub-optimal config has exposed a leak. I'll check on it tomorrow and see if the growth still seems centered around those objects listed above, and if the numbers roughly match up. Thanks -Ty
Amos
