[
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
