[
https://issues.apache.org/jira/browse/CASSANDRA-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18601:
--------------------------------------
Change Category: Operability
Complexity: Low Hanging Fruit
Mentor: David Capwell
Status: Open (was: Triage Needed)
> Repair vtable uses number of records rather than memory limits, which can
> cause more memory allocated than expected
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18601
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
> Reporter: David Capwell
> Priority: Normal
>
> The config “repair_state_size” is used by 2 caches: the coordinator side of
> repair, and the participate side of repair. At this point in time we use
> number of records rather than memory side, and the default is 100k… In one
> case it was found that there were 95k records of participate history causing
> 550mb of allocation!
> To resolve this we should:
> 1) migrate to memory size
> 2) have the 2 caches have 2 different configs (maybe you want more history
> for one than the other?); this also makes things explicit and doesn’t have
> any confusion in terms of cost (atm you can have 200k records for repair with
> a 100k limit)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
