[ https://issues.apache.org/jira/browse/CASSANDRA-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118399#comment-13118399 ]
Yang Yang commented on CASSANDRA-3287: -------------------------------------- also a cap on the total size of all row caches would also be helpful > limit row cache size as a proportion of sstable size > ---------------------------------------------------- > > Key: CASSANDRA-3287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3287 > Project: Cassandra > Issue Type: Bug > Reporter: Yang Yang > Priority: Minor > > I was debugging some problem, > then I found that my memory size increased extremely fast, > and finally reached my old gen total, and then CMS was starting all the time, > back-to-back. > even after I force a full GC, the old gen space is not decreasing any. > so I invoked invalidate cache from jmx, then did GC, now the old gen size > went down. > so it's due to row cache. > but my row cache is really not that big. > then I realized that it's due to too many small sstables. each sstable has > the same size row cache. then for the smaller sstables, it's too favorable: > they have a higher retention ratio, while in fact we can assume that the hit > ratio should be the same for all sstables, particularly if you have a random > access pattern. > if this makes sense, I can put in a simple patch on calling the constructor > of the rowcache -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira