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.
# Invalid read of size 4
{
mainInitialize-addr4
Memcheck:Addr4
...
fun:_ZL14mainInitializev
...
fun:main
}
{
mainInitialize-leak
Memcheck:Leak
...
fun:_ZL14mainInitializev
...
fun:main
}
{
cbdata-initType-leak
Memcheck:Leak
...
fun:_ZL22cbdataInternalInitType11cbdata_typePKciPFvPvE
...
fun:main
}
# These may be true leaks that should be eventually fixed (think reconfigure)
{
parseConfigFile-leak
Memcheck:Leak
...
fun:_Z15parseConfigFilePKc
...
fun:main
}
