[
https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837493#action_12837493
]
Patrick Hunt commented on ZOOKEEPER-642:
----------------------------------------
> We have bumped up tickTime to 20000 per Patrick's suggestion in another
> thread.
Hm, I'm not sure which thread you are referring to but tickTime has no impact
on this particular issue.
> "Exceeded deadline by 769ms"
> ... The message as it is has a fairly low diagnostic value.
I don't think that's the case here. Nearly 800ms is a pretty significant issue,
esp as the vm is unloaded as you mentioned.
Can you try using cli_mt instead of cli_st and see if you notice any difference?
This message "Exceeded deadline by 769ms" is saying that the ZK _client_ asked
the operating system, via the "select(..., timeout) call, to either select
something or wakeup after the specified timeout. From the select man page:
"timeout is an upper bound on the amount of time elapsed before select()
returns."
We are printing this message because select woke up 769ms later than what we
asked, which is pretty significant. Notice this has nothing to do with the
server, server settings/config or server performance, it's all local to the
client/select call. This tells me that something is up on your client, prolly
due to use of vmware. Perhaps Swapping at the host (non-virt) level? Try the
cli_mt, you might also try running w/o VMware and see what happens, it will
give you a baseline.
> "exceeded deadline by N ms" floods logs
> ---------------------------------------
>
> Key: ZOOKEEPER-642
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642
> Project: Zookeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.2.1
> Environment: virtualized linux - ec2 - ubuntu
> Reporter: Dale Johnson
> Fix For: 3.4.0
>
>
> More important zookeeper warnings are drown out by the following several
> times per minute:
> 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335:
> Exceeded deadline by 13ms
> Perhaps this is an issue with the way virtualized systems manage gettimeofday
> results?
> Maybe the current 10ms threshold could be pushed up a bit. I notice that 95%
> of the messages are below 50ms.
> Is there an obvious configuration change that I can make to fix this?
> config file below:
> # The number of milliseconds of each tick
> tickTime=2000
> # The number of ticks that the initial
> # synchronization phase can take
> initLimit=10
> # The number of ticks that can pass between
> # sending a request and getting an acknowledgement
> syncLimit=5
> # the directory where the snapshot is stored.
> dataDir=/mnt/zookeeper
> # the port at which the clients will connect
> clientPort=2181
> server.1=hbase.1:2888:3888
> server.2=hbase.2:2888:3888
> server.3=hbase.3:2888:3888
> server.4=hbase.4:2888:3888
> server.5=hbase.5:2888:3888
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
