[
https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554740#comment-14554740
]
Susan Hinrichs commented on TS-3554:
------------------------------------
Sigh. This has all been a wild goose chase. On the plus side, I'm now far
more familiar with gperftools heap-checker and heap-profiler (very nice tools).
The traffic + reload memory growth I was seeing was due to the fact that I had
not applied the patch associated with the first big fix on this bug (commit
98c87ee51b2ad91787b7a9fa2827cab1c03b3d22).
Once I started over with 5.3.x and applied the patch ts-3554-53-2.diff, the
memory growth disappeared. The fix was not backported to 5.3.0 because
[~reveller] was still seeing leaks. In your most recent tests were you running
with the patched 5.3.0? If not, please try again. For 5.3.1, we should got
ahead and port back what we have even if we do not have all of reveller's
memory leaks fixed. I'll go ahead and spin off another bug to track the
potential for session leaks. As I dug more into memory profiling, it isn't
clear that we are really running into that case.
> ATS memory leak reloading ssl_multicert.config with many ssl cert configs
> -------------------------------------------------------------------------
>
> Key: TS-3554
> URL: https://issues.apache.org/jira/browse/TS-3554
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Core, SSL
> Reporter: Steven Feltner
> Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
> Attachments: limit_session_cache_alloc.diff, ts-3554-53-2.diff,
> ts-3554-53.diff
>
>
> ATS will consume all available memory on a server with 128GB of RAM.
> @shinrich suspects it may be due to CertLookup table not being freed on a
> config reload.
> Our current process:
> - New cert comes in
> - ssl_multicert.config and remap.config updated
> - traffic_line -x
> This reload could occur as often as every 3 mins with 5000+ certs configured.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
