On 02/11/2009 06:06 PM, Amos Jeffries wrote:
>> Amos Jeffries wrote:
>>
>>> This is also popping out, and very confusing since ICAPXaction global is
>>> only created once right?
>>>
>> it is the "new PconnPool" line. It is create only once. It says its
>> reachable because the time of shutdown the icapPconnPool points on it.
>>
> ... which is preventing memPools deallocating any of it...
>
>> Should not be a problem...
>>
> Aye, the code _looks right_ but there is something fishy going on.
> Unless I'm fully mistaken on what a block is, a single call to xmalloc
> should not be generating: "155,949 blocks" in case #12, or again a single
> call to xcalloc generating "3,122 blocks" for case #2.
>
I am guessing that the blocks reported are not the blocks allocated by
that single malloc call to create icapPconnPool. They are the blocks
allocated elsewhere (e.g., ICAP connection objects, callbacks, buffers,
etc.) and tied to the pool. Valgrind did not say "leaked". It said
"reachable". Reachable via icapPconnPool global.
BTW, if we want to make sure everything is deallocated at shutdown, we
can add glue do that. I am not sure this should be a top-priority item
though.
>>> ==23075== 16,245,636 bytes in 155,949 blocks are still reachable in loss
>>> record 29 of 30
>>> ==23075== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
>>> ==23075== by 0x5C4F07: xmalloc (util.c:506)
>>> ==23075== by 0x5A591D: _GLOBAL__I_ICAPXaction.cc (SquidNew.h:48)
>>> ==23075== by 0x5C9155: (within /usr/sbin/squid3)
>>> ==23075== by 0x47E9AA: (within /usr/sbin/squid3)
>>> ==23075==
>>> ==23075==
>>> ==23075== 44,001,178 bytes in 3,122 blocks are still reachable in loss
>>> record 30 of 30
>>>
>> Are the 44Mbytes normal for a PconnPool object?
>>
> I hope not. It's meant to be a simple hash of currently active persistent
> connections.
>
It is a collection of idle persistent connections with all associated
data. Depending on the load and the time of the snapshot, 44MB can be
normal. There could be thousands of idle connections, especially if
Squid just stopped processing transactions.
HTH,
Alex.
Received on Fri Feb 13 2009 - 16:33:28 MST
This archive was generated by hypermail 2.2.0 : Fri Feb 13 2009 - 12:00:03 MST