On Wed, 2 Dec 2009 20:33:39 -0500, Linda Messerschmidt <linda.messerschmidt@xxxxxxxxx> wrote: > On Wed, Dec 2, 2009 at 10:07 AM, Linda Messerschmidt > <linda.messerschmidt@xxxxxxxxx> 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. Do you mean the SM_PAGE_SIZE which is 4096 in all Squid and used for the mem_node::data field? > > 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! The only way to be certain if its safe is to use it for a while and see what happens. If you are not so worried about wasted memory but very worried about bad effects you can safely increase it to the make mem_node align with the 8192 boundary the FreeBSD malloc is going to allocate. Or even add a padding field to do the same. Any magic numbers lying around will then be smaller than allocated size, not larger. AFAICS that will only affect the amount written to disk (minimum 2 chunks instead of 1) as meta data block and the calculation Squid does to convert the cache_mem setting to a maximum page count limit. This second in a good way. Thank you very much for tracking this down for us. And your assistance highlighting both memory problems. Amos
