hi Graham, Could you please update with some more details like the size of znode created and some of the system parameters like size of the ramdisk, size of RAM etc.. I guess this would give a better idea to compare your results with ours and discuss on improvements.
________________________________________ From: Graham (JIRA) [[email protected]] Sent: Wednesday, November 21, 2012 2:57 PM To: [email protected] Subject: [jira] [Commented] (ZOOKEEPER-866) Adding no disk persistence option in zookeeper. [ https://issues.apache.org/jira/browse/ZOOKEEPER-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502200#comment-13502200 ] Graham commented on ZOOKEEPER-866: ---------------------------------- We ran some benchmarks using zk-latencies. We tried to ways to boost performance: Using a RAM disk (tmpfs) and using libeatmydata (Makes all file system sync operations no-ops). libeatmydata benchmarks: http://pastebin.com/cNLjfhPG Ramdisk using tmpfs benchmarks: http://pastebin.com/mfe92nXn (Note: Different box to the last one) In summary: Synchronous calls are boosted by two orders of magnitude with either libeatmydata or ramdisk (In Standalone mode and also clustered mode). Asynchronous calls are boosted by a factor of 2 or 3. For tests, simulations etc. a Zookeeper without snapshots or logs makes a lot of sense, but for production use, the ramdisk or eatmydata options both looks pretty good. Another thing we found works well is to have a battery backed raid array; writes to go to raid cache and will sync to disk eventually. > Adding no disk persistence option in zookeeper. > ----------------------------------------------- > > Key: ZOOKEEPER-866 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-866 > Project: ZooKeeper > Issue Type: New Feature > Reporter: Mahadev konar > Assignee: Mahadev konar > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-nodisk.patch > > > Its been seen that some folks would like to use zookeeper for very fine > grained locking. Also, in there use case they are fine with loosing all old > zookeeper state if they reboot zookeeper or zookeeper goes down. The use case > is more of a runtime locking wherein forgetting the state of locks is > acceptable in case of a zookeeper reboot. Not logging to disk allows high > throughput on and low latency on the writes to zookeeper. This would be a > configuration option to set (ofcourse the default would be logging to disk). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
