cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12966) Gossip thread slows down when using batch commit log
Date Thu, 08 Dec 2016 13:37:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15732231#comment-15732231
] 

Jason Brown commented on CASSANDRA-12966:
-----------------------------------------

Ok, I like that :). Makes for better testability, as well, when the caller provides it's own
executor. I'll go ahead and make that changes, then. thanks

> Gossip thread slows down when using batch commit log
> ----------------------------------------------------
>
>                 Key: CASSANDRA-12966
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12966
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jason Brown
>            Assignee: Jason Brown
>            Priority: Minor
>
> When using batch commit log mode, the Gossip thread slows down when peers after a node
bounces. This is because we perform a bunch of updates to the peers table via {{SystemKeyspace.updatePeerInfo}},
which is a synchronized method. How quickly each one of those individual updates takes depends
on how busy the system is at the time wrt write traffic. If the system is largely quiescent,
each update will be relatively quick (just waiting for the fsync). If the system is getting
a lot of writes, and depending on the commitlog_sync_batch_window_in_ms, each of the Gossip
thread's updates can get stuck in the backlog, which causes the Gossip thread to stop processing.
We have observed in large clusters that a rolling restart causes triggers and exacerbates
this behavior. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message