We had some trouble with etcd at work with constant leader re-election and high ...

barakm · on Feb 10, 2015

This would certainly help. High CPU was also an issue that we started to notice on 0.4.6, here with some of the NYC CoreOS guys, and that's been fixed. Chalk it up to completely redoing internal communication.

EDIT: Master election too :)

(Disclaimer: etcd dev here)

eternalban · on Feb 10, 2015

Are you guys still per spec RAFT or have you diverged at this point?

philips · on Feb 10, 2015

The team has worked _very_ carefully to follow the raft state machine as described in the paper as close as possible. For example we have a set of tests[1] that takes possible problems outlined in the original paper and implements them as unit tests.

[1] https://github.com/coreos/etcd/blob/master/raft/raft_paper_t...

_ondq · on Feb 10, 2015

Keep in mind that reads do not go through Raft by default, so it's possible to get stale data.

They've added "consistent=true"/"quorum=true" URL parameters for GETs per https://github.com/coreos/etcd/issues/741 as a workaround.

wereHamster · on Feb 10, 2015

I had problems due to high-cpu load as well. Haven't had an issue since I updated to latest etcd sometime late last year.

hurrycane · on Feb 11, 2015

I had the same issues last around July - August and continued upgrading as they release new versions and somewhere along the way it got fixed.

You can also had to fine tune some timeouts (election and compression if I remember correctly) to get the best performance out it.

AYBABTME · on Feb 10, 2015

Pretty sure the high-cpu issue was a time.Ticker leak that was fixed earlier.