Details
-
Improvement
-
Status: Open
-
Normal
-
Resolution: Unresolved
Description
Most customers deploy with non-optimal configurations. Examples include compaction throttle, streaming throttle, RPC requests threadpool size, which are set too aggressively or too conservatively. Often these problems aren't discovered until the cluster is in the field, and the problem will manifest as a critical outage. This results in the perception that Cassandra "falls over" without warning. Because it's difficult to ship with a set of tuning parameters that are valid for all or even most scenarios I propose that we use a PID algorithm to automatically tune several key parameters. The goal of the PID would be to keep load within a healthy range. If the user chooses they could always revert to explicitly defined configuration.