Hi Ted,
Again, greatly appreciate the insightful GC tuning tips! Though we've had
some GC tuning, I believe we still have something to do further based on
profiling.
I am so glad I've got so many valuable suggestions from the ZK community!
-Huizhi
On Tue, Jul 28, 2020 at 6:27 PM Ted Dunning wr
Hi Michael,
Thanks very much for the awesome suggestions! These are brilliant!
Personally I've learned the experience.
We've had some tunings, eg. GC tuning, adding observers, etc.. But
internally on Processors, we don't touch those.
And now we are in the process of upgrading ZK from 3.4+ to 3.6.
Hi Enrico,
Thanks for pointing me to BookKeeper. I've heard about it but haven't got a
chance to really try it yet. It looks very promising. We will definitely
evaluate this direction.
-Huizhi
On Mon, Jul 27, 2020 at 10:53 PM Enrico Olivelli
wrote:
> Huizhi,
> If you want to achieve total ato
Michael's suggestions are excellent, particularly the use of observers and
the general warning to measure first.
To expand his point about GC, consider moving to more recent JVM if GC is
demonstrated to be the problem. To find out if it is a problem, turn on GC
logging and see if GC delays corresp
I agree with Ted's comments on the philosophy of scaling and the need to
recheck your use case to justify if ZooKeeper is the long term solution or
not.
That said, I was in a similar position and had gone through similar scaling
challenges for ZooKeeper so I could probably provide some suggestions
Huizhi,
If you want to achieve total atomic broadcast and have a greater throughput
you can consider using Zookeeper brother Apache Bookkeeper, that is built
over ZK, it is very lightweight and scalable (no central coordination
servers).
https://bookkeeper.apache.org
Hope that helps
Enrico
Il Ma
Hi Ted,
Thank you so much for the reply. Your suggestion is very valuable. I do
agree that we should migrate from ZK to a distributed DB for this high
number of writes. Due to legacy codebase and usage, it may not be that easy
for us to do that. So we are considering multi() as a short/mid term
so
This sounds like you are using ZK outside of the intended design. The idea
is that ZK is a coordination engine. If you have such high write rates that
ZK is dropping connections, you probably want a distributed database of
some kind, perhaps one that uses ZK to coordinate itself. ZK is a form of
re
Hi Ted,
Thank you very much for the reply! I didn't receive the reply in my email
but I found it in ZK dev mail thread. So I could not reply directly to the
thread.
I really appreciate a reply from the original author of multi()! And your
blog (A Tour of the Multi-update For Zookeeper) is very he
On Mon, Jul 27, 2020 at 1:40 PM Huizhi Lu wrote:
> Hi Zookeeper Devs,
>
> Hope this email finds you well!
>
> I am working on some stuff that needs ZK multi(). I would like to confirm a
> few things about this API.
>
> 1. Is this a real transaction operation in ZK? My understanding is, it is a
>
Hi Zookeeper Devs,
Hope this email finds you well!
I am working on some stuff that needs ZK multi(). I would like to confirm a
few things about this API.
1. Is this a real transaction operation in ZK? My understanding is, it is a
real transaction. If I put 3 write operations in this transaction
11 matches
Mail list logo
