hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8674) Improve performance of postponed block scans
Date Tue, 18 Oct 2016 00:18:58 GMT

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

Hadoop QA commented on HDFS-8674:
---------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  0s{color} | {color:blue}
Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} | {color:red}
HDFS-8674 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HDFS-8674 |
| JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12778098/HDFS-8674.patch
|
| Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/17194/console |
| Powered by | Apache Yetus 0.4.0-SNAPSHOT   http://yetus.apache.org |


This message was automatically generated.



> Improve performance of postponed block scans
> --------------------------------------------
>
>                 Key: HDFS-8674
>                 URL: https://issues.apache.org/jira/browse/HDFS-8674
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>    Affects Versions: 2.6.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>            Priority: Critical
>         Attachments: HDFS-8674.patch, HDFS-8674.patch
>
>
> When a standby goes active, it marks all nodes as "stale" which will cause block invalidations
for over-replicated blocks to be queued until full block reports are received from the nodes
with the block.  The replication monitor scans the queue with O(N) runtime.  It picks a random
offset and iterates through the set to randomize blocks scanned.
> The result is devastating when a cluster loses multiple nodes during a rolling upgrade.
Re-replication occurs, the nodes come back, the excess block invalidations are postponed.
Rescanning just 2k blocks out of millions of postponed blocks may take multiple seconds. During
the scan, the write lock is held which stalls all other processing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message