[
https://issues.apache.org/jira/browse/CASSANDRA-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771655#comment-17771655
]
Abe Ratnofsky commented on CASSANDRA-18904:
-------------------------------------------
I have a patch for this - currently working on rebasing it on David's work from
CASSANDRA-18816
> Repair vtable caches consume excessive memory
> ---------------------------------------------
>
> Key: CASSANDRA-18904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18904
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Caching
> Reporter: Abe Ratnofsky
> Assignee: Abe Ratnofsky
> Priority: Normal
>
> Currently, the repair vtables
> (system_views.{repairs,repair_sessions,repair_jobs,repair_participates,repair_validations})
> are backed by caches in ActiveRepairService that are bounded by the number
> of elements in them, controlled by Config.repair_state_size and
> Config.repair_state_expires.
> The individual cached elements are mutable, and can grow to retain a
> significant amount of heap as the instance uptime increases and more repairs
> are run. In a heap dump for a real cluster, I found these caches occupying
> ~1GB of heap total between ActiveRepairService.repairs and
> ActiveRepairService.participates. Individual cached elements were reaching
> 100KB in size, so configuring the caches by number of elements introduces a
> significant amount of potential variance in the actual heap usage of these
> caches.
> We should measure these caches by the heap they retain, not by the number of
> elements. Users should not be expected to check heap dumps to calibrate the
> number of elements they configure the caches to consume - specifying a memory
> total is much more user-friendly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
