[ https://issues.apache.org/jira/browse/CASSANDRA-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149002#comment-16149002 ]
Markus Dlugi commented on CASSANDRA-13754: ------------------------------------------ [~snazy], I checked out the 13754-ftl-leak-3.11 branch and ran our load test with your patches. Unfortunately, the memory leak is still there, Cassandra first starts GCing like crazy and then throws an {{OutOfMemoryError}} after a while. So it seems like the call to {{FastThreadLocal.removeAll()}} is not properly executed. Actually, while writing this it just struck me why that is the case. The thread created in {{SEPWorker}} does not stop after it finishes, but is instead returned to the pool and picks up new tasks. So it will never leave the {{run()}} method, and therefore also never execute {{FastThreadLocal.removeAll()}}. So I think we will have to include that call in the {{SEPWorker}} itself. > FastThreadLocal leaks memory > ---------------------------- > > Key: CASSANDRA-13754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13754 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Cassandra 3.11.0, Netty 4.0.44.Final, OpenJDK 8u141-b15 > Reporter: Eric Evans > Assignee: Robert Stupp > Fix For: 3.11.1 > > > After a chronic bout of {{OutOfMemoryError}} in our development environment, > a heap analysis is showing that more than 10G of our 12G heaps are consumed > by the {{threadLocals}} members (instances of {{java.lang.ThreadLocalMap}}) > of various {{io.netty.util.concurrent.FastThreadLocalThread}} instances. > Reverting > [cecbe17|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=cecbe17e3eafc052acc13950494f7dddf026aa54] > fixes the issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org