[
https://issues.apache.org/jira/browse/CASSANDRA-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-1469:
----------------------------------------
Attachment: 0002_determine_memtable_thresholds_at_runtime.txt
Patch to set memtable thresholds at runtime based on the amount of heap
available. One fifth of the heap goes to the memtable, and the op threshold is
based on $HEAP / 64 * 0.3. Of course if someone makes a bunch of memtables
this will be too aggressive, but hopefully anyone seriously running Cassandra
in production is explicitly declaring these settings.
> adaptive default heap size
> --------------------------
>
> Key: CASSANDRA-1469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1469
> Project: Cassandra
> Issue Type: New Feature
> Components: Packaging
> Reporter: Jonathan Ellis
> Assignee: Brandon Williams
> Fix For: 0.7.0
>
> Attachments: 0001_adaptively_determine_heap_size.txt,
> 0002_determine_memtable_thresholds_at_runtime.txt
>
>
> Cassandra comes out of the box with very conservative defaults, especially in
> -Xmx and memtable sizes, which leads to complaints of poor performance or
> even OOM conditions under heavy load. But changing these to be aggressive
> can cause the same problem: most servers enable swap out of the box, so
> asking for a 4GB or 8GB heap could allocate happily but also cause problems
> when it starts paging.
> Proposed solution is to update the start script to set Xmx to half of system
> ram ("free -m | awk '/Mem:/ {print $2}'"). Memtable defaults will have to be
> handled by Java, but we can do that based on heap size (Runtime.maxMemory).
> An alternative suggestion was to provide "small", "medium", "large"
> configurations, but this plays poorly with rpm and deb packages. I think the
> adaptive approach is more promising.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
