[
https://issues.apache.org/jira/browse/HDFS-15621?focusedWorklogId=575577&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-575577
]
ASF GitHub Bot logged work on HDFS-15621:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 01/Apr/21 15:40
Start Date: 01/Apr/21 15:40
Worklog Time Spent: 10m
Work Description: sodonnel opened a new pull request #2849:
URL: https://github.com/apache/hadoop/pull/2849
This is a relatively simple change to reduce the memory used by the
Directory Scanner and also simplify the logic in the ScanInfo object.
This change ensures the same File object is re-used for all blocks in a
directory. Previously a large part of the path was repeated for each block file.
Aside from that, the logic of the directory scanner remains the same.
Comparing heap dumps, the memory used by 100K blocks goes from ~35MB to
19MB. Or 350MB per 1M blocks down to 190MB per 1M blocks. This is a reduction
of about 46%.
--
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: 575577)
Remaining Estimate: 0h
Time Spent: 10m
> Datanode DirectoryScanner uses excessive memory
> -----------------------------------------------
>
> Key: HDFS-15621
> URL: https://issues.apache.org/jira/browse/HDFS-15621
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode
> Affects Versions: 3.4.0
> Reporter: Stephen O'Donnell
> Assignee: Stephen O'Donnell
> Priority: Major
> Attachments: Screenshot 2020-10-09 at 14.11.36.png, Screenshot
> 2020-10-09 at 15.20.56.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We generally work a rule of 1GB heap on a datanode per 1M blocks. For nodes
> with a lot of blocks, this can mean a lot of heap.
> We recently captured a heapdump of a DN with about 22M blocks and found only
> about 1.5GB was occupied by the ReplicaMap. Another 9GB of the heap is taken
> by the DirectoryScanner ScanInfo objects. Most of this memory was alloated to
> strings.
> Checking the strings in question, we can see two strings per scanInfo,
> looking like:
> {code}
> /current/BP-671271071-10.163.205.13-1552020401842/current/finalized/subdir28/subdir17/blk_1180438785
> _106716708.meta
> {code}
> I will update a screen shot from MAT showing this.
> For the first string especially, the part
> "/current/BP-671271071-10.163.205.13-1552020401842/current/finalized/" will
> be the same for every block in the block pool as the scanner is only
> concerned about finalized blocks.
> We can probably also store just the subdir indexes "28" and "27" rather than
> "subdir28/subdir17" and then construct the path when it is requested via the
> getter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
