[squid-users] Memory Leak Squid 3.4.9 on FreeBSD 10.0 x64

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/12/2014 11:17 a.m., Doug Sampson wrote:
>> On 26/11/2014 8:59 a.m., Doug Sampson wrote:
>>> 
>>> Thanks, Amos, for your pointers.
>>> 
>>> I've commented out all the fresh_patterns lines appearing
>>> above the last two lines.
>>> 
>>> I also have dropped diskd in favor of using aufs exclusively, 
>>> taking out the min-size parameter. I've commented out the 
>>> diskd_program support option. In the previous version of squid 
>>> (2.7) I had split the cache_dir into two types with great
>>> success using coss and aufs. Previously I had only aufs and
>>> performance wasn't where I wanted it. Apparently coss is no
>>> longer supported in the 3.x version of squid atop FreeBSD.
>> 
>> COSS has been replaced with Rock storage type in Squid-3. They
>> should be used in roughly similar ways in terms of traffic
>> optimization.
>> 
>>> 
>>> The pathname for the cache swap logs have been fixed.
>>> Apparently this came from a squid.conf example that I copied in
>>> parts. Would this be the reason why we are seeing the error
>>> messages in /var/log/messages regarding swapping mentioned in
>>> my original post?
>> 
>> No. I think that is coming out of the OS kernel memory
>> management. It uses the term "swap" as well in regards to disk
>> backed virtual memory.
>> 
>> If your system is "swapping" (using that disk backed "swap
>> memory") while running Squid then you will get terrible
>> performance as a matter of course since the Squid cache index and
>> cache_meme is often very large in RAM and accessed often.
>> 
>>> 
>>> The hierarchy_stoplist line has been stripped out as you say it
>>> is deprecated.
>>> 
>>> The mem .TSV file is attached herewith.
>>> 
>>> Currently I have the cache_dir located on the OS disk and all
>>> of the cache logging files on a second drive. Is this the
>>> optimal setup of cache-dir and logs?
>> 
>> I would do it the other way around. Logs are appended with a
>> small amount of data each transaction, whereas the main cache_dir
>> has a relativey large % of the bandwidth throughput being written
>> out to it constantly (less % in recent Squid, but still a lot).
>> The dik most likely to die early is the one holding cache_dir.
>> 
> I'm still running into the issue of being out of available space in
> the swapfile on my system. I've attached another TSV file
> indicating the various type of memory being in use and whatnot. Is
> there anything in there that screams out?
> 

Nothing particularly stands out as leaking. Although the cache memory
pages (mem_node) in-use size is suspiciously close to half what you
say the OS is reporting.

That makes me suspect that your OS is rounding up its allocations to
8KB of memory for each node. If that is the case the simplest
workaround is to reduce cache_mem size down to below the point where
the box will swap.


If you are game for it I have been wondering if we need to enable
chunking for 64-bit systems. To test that run squid with environment
variable MEMPOOLS=1.
 Memory should then be allocated in larger blocks, but utilized much
more compactly within those blocks for an overall saving on objects
like mem_node. It is currently a rarely used feature though, so I'm
not sure if there are any issues hiding.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUgptwAAoJELJo5wb/XPRjLbUIAJjORv/denfKNTA53cxrN7CU
Cbyc3m6yqiM4Mi0J0VNS2qPUJYd69sSGkz4Q4XtpoKLPjO8i8glcVDg8ncoKMokj
E3rJbpj4tcdukPmvJ8XlQRqlAfYANTQK6wGvfhmQOlNqPjtKi6eB7HZR75LWNFlM
aj/6Ij15cfM0OI9KQW5PyKwxLwTmZhDn3g0RTHdbzho9GZOjfZEYA0Wn2eMDNqOM
JIwsamBp6KFCN7w/6Mw2I0+guVOpFALDd35M39HdapEuzwauuNrt5F1DvD+rSIa+
8iBKRcDtB3tsaFWyIilFoxCbTTdtdggDhiN0FfT/KEebtZb+A5PI+IQIFWszNzc=
=5tf8
-----END PGP SIGNATURE-----