Page MenuHomePhabricator

Evaluate increased memtable_cleanup_threshold values
Open, LowPublic

Description

I'm hearing from others that Cassandra's default (calculated) value for memtable_cleanup_threshold is a bit too aggressive (too low), resulting in overly frequent flushing of the largest tables, higher disk IO, and a larger number (of smaller) SSTables, (which in turn creates more compaction activity). I believe this is true for us as well; Our calculated threshold in the RESTBase cluster is only 33% (which does strikes me as quite low).

One side-effect of more frequent memtable flushing is a higher demand for memtable flush writers, and the following plot of pending memtable flush writer jobs would seem to indicate that there is some room for improvement.

Screenshot from 2016-05-04 21-03-36.png (829×1 px, 111 KB)

I propose some limited single node experiments of higher values, while monitoring flush frequency, and memtable flush writer pending tasks.

Event Timeline

Eevans triaged this task as Low priority.May 5 2016, 2:13 AM
Eevans added subscribers: JAllemandou, elukey, fgiunchedi.
GWicke edited projects, added Services (attic); removed Services.

@Eevans: Could you please answer the last comment? Thanks in advance!

Aklapper changed the task status from Stalled to Open.Oct 19 2020, 4:34 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status.

(Smallprint, as general orientation for task management: If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead. If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks. If this task is stalled on an upstream project, then the Upstream tag should be added. If this task requires info from the task reporter, then there should be instructions which info is needed. If this task needs retesting, then the TestMe tag should be added. If this task is either out of scope and nobody should ever work on this, or nobody else managed to reproduce the problem described in this task, then this task should have the "Declined" status. If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)

@Eevans: Could you please answer the last comment? Thanks in advance!

Still relevant AFAIK