[
https://issues.apache.org/jira/browse/CASSANDRA-17763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570101#comment-17570101
]
Romain Hardouin commented on CASSANDRA-17763:
---------------------------------------------
I like the idea because we use the same workaround (stopping native interface).
But what is a _good_ threshold? I try to figure out an automatic threshold
based on available resources (e.g. num cores) but it's way too brittle. There
is no one-size-fits-all solution (clock speed, disk IO/bandwith, read latency
SLO, ...). Before starting native interface again, we compare pending
compactions metric with the other nodes in the same data center, right? So this
is not a decision based on the node's metrics by itself. We have to get an idea
of the value to set ahead of time for a given data center.
Therefore, I think that pending compactions threshold would be defined using a
new (command line) parameter.
Other ideas?
> Allow node to serve traffic only once compactions settle
> --------------------------------------------------------
>
> Key: CASSANDRA-17763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17763
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Compaction
> Reporter: Gil Ganz
> Priority: Normal
> Fix For: 4.x
>
>
> Today when nodes are joined to the cluster, once data streaming is completed,
> node starts serving traffic, but it's possible there are a lot of pending
> compactions, so having reads accessing sstables during that time is going to
> make these reads slower and load the server. In some cases performance is so
> bad it can bring the application down.
> Today I overcome this by stopping native transport to a node after join
> finishes, and enabling it after compactions pending reach a certain
> threshold, it would be nice to have that as part of the join process, only
> consider join completed once there are not that many compactions pending.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
