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

Harsh J commented on HDFS-3475:
-------------------------------

Btw I finally played around with the block repl multiplier on a local cluster 
and I could notice increase in usage when a DN went down and the blocks began 
moving about, with a higher multiplier value. The logs grepped and counted too 
showed higher "asking DN to replicate" count per DN heartbeat at NN.

This should be cautiously increased though, cause even if your network is 
awesome, your disks cumulatively need to keep up with it anyway. And too much 
of payload per DN command transfer-back is bad as well. This is why the 
defaults, I've stuck them as-is and added warnings in documented props.
                
> Make the replication monitor multipliers configurable
> -----------------------------------------------------
>
>                 Key: HDFS-3475
>                 URL: https://issues.apache.org/jira/browse/HDFS-3475
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>    Affects Versions: 2.0.0-alpha
>            Reporter: Harsh J
>            Assignee: Harsh J
>            Priority: Trivial
>         Attachments: HDFS-3475.patch
>
>
> BlockManager currently hardcodes the following two constants:
> {code}
> private static final int INVALIDATE_WORK_PCT_PER_ITERATION = 32;
> private static final int REPLICATION_WORK_MULTIPLIER_PER_ITERATION = 2;
> {code}
> These are used to throttle/limit the amount of deletion and 
> replication-to-other-DN work done per heartbeat interval of a live DN.
> Not many have had reasons to want these changed so far but there have been a 
> few requests I've faced over the past year from a variety of clusters I've 
> helped maintain. I think with the improvements in disks and network thats 
> already started to be rolled out in production environments out there, 
> changing these may start making sense to some.
> Lets at least make it advanced-configurable with proper docs that warn 
> adequately, with the defaults being what they are today. With hardcodes, it 
> comes down to a recompile for admins, which is not something they may like.
> Please let me know your thoughts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to