[
https://issues.apache.org/jira/browse/HDFS-16043?focusedWorklogId=614971&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-614971
]
ASF GitHub Bot logged work on HDFS-16043:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jun/21 12:48
Start Date: 25/Jun/21 12:48
Worklog Time Spent: 10m
Work Description: zhuxiangyi commented on a change in pull request #3063:
URL: https://github.com/apache/hadoop/pull/3063#discussion_r658737120
##########
File path:
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
##########
@@ -3344,7 +3344,8 @@ boolean delete(String src, boolean recursive, boolean
logRetryCache)
getEditLog().logSync();
logAuditEvent(ret, operationName, src);
if (toRemovedBlocks != null) {
- removeBlocks(toRemovedBlocks); // Incremental deletion of blocks
+ blockManager.getMarkedDeleteQueue().add(
+ toRemovedBlocks.getToDeleteList());
Review comment:
> Thanks for the work and sharing the flame graph, which makes it easy
to validate the change.
>
> However, I am still not able to understand why the change improves delete
performance. The delete op is done in two steps, step 1 acquire lock, collect
blocks, release lock. step 2 acquire lock, delete blocks, release lock.
>
> The change essentially moves the step2 to another thread. IMO, this
approach reduces client perceived latency, which is good. But deleting the
blocks still requires holding namespace lock. Why does it avoid NN
unresponsiveness?
>
> Is it because instead of releasing the lock after a specified number of
blocks, it releases the lock after an absolute time. I can image the absolute
time is a better metric because deleting a block does take a variable duration
of time, not constant.
>
> A few minor comments changes requested:
Thanks for your comment, as you have commented, the current modification is
just to delete the block asynchronously. The QuotaCount calculation
optimization described in jira can reduce the time to collect blocks. I plan to
open a new problem to solve it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 614971)
Time Spent: 2h 40m (was: 2.5h)
> HDFS : Delete performance optimization
> --------------------------------------
>
> Key: HDFS-16043
> URL: https://issues.apache.org/jira/browse/HDFS-16043
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs, namanode
> Affects Versions: 3.4.0
> Reporter: Xiangyi Zhu
> Assignee: Xiangyi Zhu
> Priority: Major
> Labels: pull-request-available
> Attachments: 20210527-after.svg, 20210527-before.svg
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> The deletion of the large directory caused NN to hold the lock for too long,
> which caused our NameNode to be killed by ZKFC.
> Through the flame graph, it is found that its main time-consuming
> calculation is QuotaCount when removingBlocks(toRemovedBlocks) and deleting
> inodes, and removeBlocks(toRemovedBlocks) takes a higher proportion of time.
> h3. solution:
> 1. RemoveBlocks is processed asynchronously. A thread is started in the
> BlockManager to process the deleted blocks and control the lock time.
> 2. QuotaCount calculation optimization, this is similar to the optimization
> of this Issue HDFS-16000.
> h3. Comparison before and after optimization:
> Delete 1000w Inode and 1000w block test.
> *before:*
> remove inode elapsed time: 7691 ms
> remove block elapsed time :11107 ms
> *after:*
> remove inode elapsed time: 4149 ms
> remove block elapsed time :0 ms
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
