Re: [squid-users] Squid 3.3 is very aggressive with memory

Alright, it took me a little longer to get information than I
anticipated, but here it is. I can confirm that this is related to
HTTPS inspection.

I started by running the second instance with only transparent HTTP,
letting the first instance take care of HTTPS as I mentioned earlier.
In this situation, the second instance memory never grew higher than
40mb, but the first still grew as expected. I then switched it around,
and ran the second instance serving only transparent HTTPS and a very
minimal config, and the second is now the one that grows. The first
one still grows, but I suspect this is due to direct proxy SSL bump,
memory pools and caching being enabled.

The second config: http://getoffmalawn.com/static/squid.conf.sslonly
I'm happy to strip this down further.

All of the following information was taken after 7.5 hours of activity:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28527 squid 15 0 1040m 931m 4680 S 23.2 30.6 19:45.00 squid -N
-f /etc/squid/squid.conf.sslonly

http://getoffmalawn.com/static/squid-manager-info.out
http://getoffmalawn.com/static/squid-manager-mem.out

So at this point, I'm not sure what I should be doing to progress
this. I'm happy to add any debugging, just need to tell me where its
should go. I'll keep trying to get Valgrind going in the mean time.

Thanks,

Nathan.

--
Nathan Hoad
Software Developer
www.getoffmalawn.com
On Sat, Jan 4, 2014 at 7:57 PM, Nathan Hoad <nathan_at_getoffmalawn.com> wrote:
> Apologies for the delay in responding - I have not had reliable
> Internet or VPN access for a few days, as well as being on holiday.
>
> I have attempted to run valgrind in a lab setting with the given
> parameters, but I found that it eventually it locked up the entire
> machine, so it is possible that I won't be able to run under valgrind.
> That was on a virtual machine though, so I will attempt running it on
> a proper hardware based machine to see if it helps at all - I will
> come back on Monday with more information.
>
> Thanks,
>
> Nathan.
> --
> Nathan Hoad
> Software Developer
> www.getoffmalawn.com
>
>
> On Mon, Dec 23, 2013 at 4:52 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 12/22/2013 12:39 AM, Nathan Hoad wrote:
>>> On Wed, Dec 18, 2013 at 4:54 PM, Alex Rousskov wrote:
>>>> I recommend the following next steps:
>>>> 1. Set "memory_pools off".
>>>> 2. Disable all caching with "cache deny all".
>>>>
>>>> Do you see as similar memory growth pattern after the above two steps?
>>
>>
>>> I do see a similar pattern, although slowed [...] I'm
>>> happy to go in the other direction and raise the size of the memory
>>> pools, if that could be something useful.
>>
>> No, please keep memory pools off and caching disabled for as long as you
>> can -- it simplifies triage.
>>
>>
>>> I have got an ALL,9 log, but I am hesitant to unleash it on anyone as
>>> it is a 20gb file, from start to stop. If there is interest, I can
>>> still upload it - it compresses down to 1.7gb.
>>
>> I will email you upload instructions privately.
>>
>>
>>> Running valgrind produces repeated, spurious errors
>>
>> Could be a platform-specific issue, bit if you have not ./configured
>> Squid --with-valgrind-debug and --disable-optimizations, please do so
>> and repeat the valgrind test. If valgrind works after that configuration
>> change, post or upload the resulting valgrind log (keeping Squid's
>> debug_options at ALL,1).
>>
>> Here is a valgrind configuration that you may find useful (adjust as
>> needed):
>>
>>> valgrind -v
>>> --trace-children=yes
>>> --num-callers=30
>>> --log-file=valgrind-%p.log
>>> --leak-check=full
>>> --show-reachable=no
>>> --suppressions=valgrind.supp
>>
>> The suppression file is attached (it is outdated and incomplete but
>> probably still helps).
>>
>> Please note that valgrind slows Squid down a lot.
>>
>>
>> Thank you,
>>
>> Alex.
>>