[ https://issues.apache.org/jira/browse/CASSANDRA-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295275#comment-16295275 ]
Jeff Jirsa commented on CASSANDRA-9805: --------------------------------------- OK, we'll leave it open. I suspect that a bit of garbage here is probably "normal". It's not leaking, it's being collected, though maybe there's room for improvement to minimize allocations. > nodetool status causes garbage to be accrued > -------------------------------------------- > > Key: CASSANDRA-9805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9805 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04 64-bit > Cassandra 2.0.14 > Java 1.7.0 OpenJDK > Reporter: Andy Caldwell > Attachments: JVM-heap-usage.png > > > As part of monitoring our Cassandra clusters (generally 2-6 nodes) we were > running `nodetool status` regularly (~ every 5 minutes). On Cassandra 1.2.12 > this worked fine and had negligible effect on the Cassandra database service. > Having upgraded to Cassandra 2.0.14, we've found that, over time, the tenured > memory space slowly fills with `RMIConnectionImpl` objects (and some other > associated objects) until we start running into memory pressure and > triggering proactive and then STW GC (which obviously impact performance of > the cluster). It seems that these objects are kept around long enough to get > promoted to tenured from Eden and then don't get considered for collection > (due to internal reference cycles?). > Very easy to reproduce, just call `nodetool status` in a loop and watch the > memory usage climb to capacity then drop to empty after STW. No need to be > accessing the DB keys at all. -- 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