[ 
https://issues.apache.org/jira/browse/HDFS-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890957#comment-15890957
 ] 

Benoy Antony edited comment on HDFS-11384 at 3/1/17 8:17 PM:
-------------------------------------------------------------

Sleeping inside the *Synchronized* block should be avoided as it will prevent 
other threads from obtaining the lock while the thread is sleeping. 
One tradeoff in sleeping fixed vs variable time is that code gets complicated. 
Since by default, the delay is not applied, it is okay to sleep for a fixed 
interval after getBlocks(). 


was (Author: benoyantony):
Sleeping inside the *Synchronized* block should be avoided as it will lock 
prevent other threads from obtaining the lock while the thread is sleeping. 
One tradeoff in sleeping fixed vs variable time is that code gets complicated. 
Since by default, the delay is not applied, it is okay to sleep for a fixed 
interval after getBlocks(). 

> Add option for balancer to disperse getBlocks calls to avoid NameNode's 
> rpc.CallQueueLength spike
> -------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-11384
>                 URL: https://issues.apache.org/jira/browse/HDFS-11384
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: balancer & mover
>    Affects Versions: 2.7.3
>            Reporter: yunjiong zhao
>            Assignee: yunjiong zhao
>         Attachments: balancer.day.png, balancer.week.png, HDFS-11384.001.patch
>
>
> When running balancer on hadoop cluster which have more than 3000 Datanodes 
> will cause NameNode's rpc.CallQueueLength spike. We observed this situation 
> could cause Hbase cluster failure due to RegionServer's WAL timeout.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to