ZK does a good enough job at avoiding seeks that if you give it some
dedicated disks, you may not see much speedup with SSD's.
On Fri, Dec 18, 2009 at 9:13 AM, Thiago Borges thbor...@gmail.com wrote:
Maybe in some specifically environment as described in ZOOKEEPER-546. But
yes, I agree, it's
I read the documentation at zoo site and can't find some text about
sharing/limits of zoo clients connections.
I only see the parameter in .conf file about the max number of
connections per client.
Can someone point me some documentation about sharing the zookeeper
connections? Can I do
Thiago Borges wrote:
I read the documentation at zoo site and can't find some text about
sharing/limits of zoo clients connections.
No limits in particular to ZK itself (given enough memory) - usually the
limitations are due to the max number of file descriptors the host OS
allows. Often
On 16/12/2009 16:45, Patrick Hunt wrote:
This test has 910 clients (sessions) involved:
http://hadoop.apache.org/zookeeper/docs/current/zookeeperOver.html#Performance
We have users with 10k sessions accessing a single 5 node ZK ensemble.
That's the largest I know about that's in production.
I think that htis would be a very bad idea because of restart issues. As it
stands, ZK reads from disk snapshots on startup to avoid moving as much data
from other members of the cluster.
You might consider putting the snapshots and log on a tmpfs file system if
you really, really want this.
On
I agree with Ted, it doesn't seem like a good idea to do in practice.
however, you do have a couple of options if you are just testing things:
1) use tmpfs
2) you can set forceSync to no in the configuration file to disable
syncing to disk before acknowledging responses
3) if you really want
