On Wed, Dec 2, 2009 at 10:07 AM, Linda Messerschmidt
<linda.messerschmidt_at_gmail.com> wrote:
> For example, I noticed that the size of the mem_node object is 4112
> bytes and we have 2499136 of them at present. Suppose that each one
> of those allocations had to be filled with two 4K pages (8192 bytes).
> That would "waste" 4080 bytes per allocation, or about 9957495KB,
> which would explain what we're seeing. I totally understand that
> that's a grossly oversimplified example and not how squid's
> memorypool-based allocation really works, so that's probably not
> *actually* what's happening. I just offer it as an explanation of
> what the problem "feels like." I, unfortunately, understand neither
> squid's memory allocation practices nor the FreeBSD malloc()
> implementation well enough to offer a more accurate guess.
This may not have been as far off the mark as I thought.
I did read the malloc man page in detail, and while I don't understand
it all, the gist of it is that allocations of a size between 512 bytes
and 1 megabyte are rounded up to the next power of two (or 8, or 16,
I'm not totally clear on that). So the 4112 byte allocation does
indeed get "rounded up" to 8192 bytes.
I found the definition of the mem_node structure and saw that its size
was set in a #define. I changed the #define size to make the
resulting structure 4096 bytes instead of 4112 and this is the result
so far:
Storage Mem size: 4194084 KB
Maximum Resident Size: 4535900 KB
Total accounted: 4410647 KB
(Without this change, squid would have been at 8800000+ KB resident size.)
I am not 100% comfortable that this is a safe change though because
there is always a chance that somewhere in the code assumes this
buffer is the original size and doesn't use the #define. Nor do I
know what else might be harmed by changing the size.
The better solution is probably to leave the size as-is and figure out
how to interoperate better with FreeBSD's malloc implementation
instead. But I'm afraid that's quite beyond me. :)
Thanks!
Received on Thu Dec 03 2009 - 01:33:42 MST
This archive was generated by hypermail 2.2.0 : Thu Dec 03 2009 - 12:00:01 MST