[ https://issues.apache.org/jira/browse/CASSANDRA-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032878#comment-14032878 ]
T Jake Luciani edited comment on CASSANDRA-7402 at 6/16/14 8:21 PM: -------------------------------------------------------------------- This isn't going to fix the underlying issue (reads/queries are overcapacity) but it will tell an operator that reads are too high vs just wondering what's happening to the system. Similar to the purpose of memtable_cleanup_threashold was (Author: tjake): This isn't going to fix the underlying issue (reads/queries are overcapacity but it will tell an operator that reads are too high vs just wondering what's happening to the system). Similar to the purpose of memtable_cleanup_threashold > limit the on heap memory available to requests > ---------------------------------------------- > > Key: CASSANDRA-7402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7402 > Project: Cassandra > Issue Type: Improvement > Reporter: T Jake Luciani > Fix For: 3.0 > > > When running a production cluster one common operational issue is quantifying > GC pauses caused by ongoing requests. > Since different queries return varying amount of data you can easily get your > self into a situation where you Stop the world from a couple of bad actors in > the system. Or more likely the aggregate garbage generated on a single node > across all in flight requests causes a GC. > We should be able to set a limit on the max heap we can allocate to all > outstanding requests and track the garbage per requests to stop this from > happening. It should increase a single nodes availability substantially. > In the yaml this would be > {code} > total_request_memory_space_mb: 400 > {code} > It would also be nice to have either a log of queries which generate the most > garbage so operators can track this. Also a histogram. -- This message was sent by Atlassian JIRA (v6.2#6252)