zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Benediktson <dbenedikt...@twitter.com.INVALID>
Subject Re: etcd performance comparison
Date Wed, 22 Feb 2017 00:32:30 GMT
I kind of wonder about them only using one disk. I haven't experimented
with this in ZooKeeper, nor have I ever been a DBA, but with traditional
database systems (which ZooKeeper should be basically identical to, in this
regard), it's a pretty common recommendation to put snapshots and TxLogs on
different drives, for the obvious reason of avoiding one of the biggest
problems laid out in that blog post: when snapshot happens, it contends
with your log flushes, causing write latencies to explode. Suddenly you
have tons more IO, and where it used to be nicely sequential, now it's
heavily randomized because of the two competing writers. It's kind of the
nature of benchmarks that there's always something you can nitpick, but
still, I feel like they're running a questionable configuration.

They mention that ZK snapshots "stop the world", and maybe I'm mistaken,
but I didn't think that was right - I thought they were just slowing
everything down because they write a lot and contend a lot. I'm pretty sure
ZK snapshots are fuzzy over a range of transactions, and transactions keep
applying during the snapshot, right?

Thanks,
Dan

On Tue, Feb 21, 2017 at 2:24 PM, Benjamin Mahler <bmahler@mesosphere.io>
wrote:

> I'm curious if folks here have seen the following write performance
> comparison that was done by CoreOS on etc, Consul, and ZooKeeper:
> https://coreos.com/blog/performance-of-etcd.html
>
> Sounds like performance comparison of reads and updates are coming next.
> Are there any thoughts from folks here on this comparison so far?
>
> Thanks,
> Ben
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message