Still no valgrind-appended info appended to the mgr:mem. 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.
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
On Sep 26, 2012, at 6:50 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 27.09.2012 12:15, tcr_at_raynersw.com wrote:
>> Following up on this thread (which I inadvertently hijacked):
>> http://squid-web-proxy-cache.1019090.n4.nabble.com/FATAL-Rock-cache-dir-at-cache-rock-failed-to-open-db-file-2-No-such-file-or-directory-td4656753.html
>>
>> I've started running a valgrind enabled squid 3.2.1 on one of my
>> proxies. Squid is currently running just under 1GB of RAM and will
>> continue to grow and grow. Here is the output from squidclient mgr:mem
>>
>> http://bit.ly/QxXL3f
>>
>> Not too familiar with valgrind, but is there some way that I can mark
>> a baseline right now, and then run it again later to see which objects
>> are continuing to be allocated and not freed, now that the server is
>> "warmed up"?
>
>
> If you wish. That report though is not related to valgrind, it is the usual mempools report of memory usage.
>
> That report contains columns for current, maximum and accumulated memory behaviour for each pooled object type squid allocates (not all objects are accounted, thus our dependence on mallinfo() and valgrind for leak detection). If the max is greater than the current then the objects are unlikely to be leaking (but no guarantee all code paths using them are the same leak-free).
>
> NP: The report is a TSV (tab separated values) format MS Excel and other spreadsheet applications can open and display for easier reading. You can graph them open two and compare differences in column values etc whatever you can imagine comparing.
>
>
> Also, has the mgr:info report got any additional details appended by valgrind that were not there in earlier reports?
> The valgrind report shows the details you are looking for.
>
> Amos
>
Received on Thu Sep 27 2012 - 07:38:10 MDT
This archive was generated by hypermail 2.2.0 : Thu Sep 27 2012 - 12:00:13 MDT