[ https://issues.apache.org/jira/browse/CASSANDRA-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357806#comment-15357806 ]
Jeremiah Jordan edited comment on CASSANDRA-11738 at 6/30/16 8:36 PM: ---------------------------------------------------------------------- bq. Won't using correctly calculated latencies tell a node enough to avoid a given peer? Yes, but the times I have used this are things like repairing after removing a corrupt SSTable or something. Where latency may not have been high, but I didn't want the node to be picked for reads done at ONE unless the other nodes were down. was (Author: jjordan): bq. Won't using correctly calculated latencies tell a node enough to avoid a given peer? Yes, but the times I have used this are things like repairing after removing a corrupt SSTable or something. Where latency may not have been high, but I didn't want to node to be picked for reads done at ONE unless the other nodes were down. > Re-think the use of Severity in the DynamicEndpointSnitch calculation > --------------------------------------------------------------------- > > Key: CASSANDRA-11738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11738 > Project: Cassandra > Issue Type: Improvement > Reporter: Jeremiah Jordan > Fix For: 3.x > > > CASSANDRA-11737 was opened to allow completely disabling the use of severity > in the DynamicEndpointSnitch calculation, but that is a pretty big hammer. > There is probably something we can do to better use the score. > The issue seems to be that severity is given equal weight with latency in the > current code, also that severity is only based on disk io. If you have a > node that is CPU bound on something (say catching up on LCS compactions > because of bootstrap/repair/replace) the IO wait can be low, but the latency > to the node is high. > Some ideas I had are: > 1. Allowing a yaml parameter to tune how much impact the severity score has > in the calculation. > 2. Taking CPU load into account as well as IO Wait (this would probably help > in the cases I have seen things go sideways) > 3. Move the -D from CASSANDRA-11737 to being a yaml level setting > 4. Go back to just relying on Latency and get rid of severity all together. > Now that we have rapid read protection, maybe just using latency is enough, > as it can help where the predictive nature of IO wait would have been useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)