[
https://issues.apache.org/jira/browse/HADOOP-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837408#comment-17837408
]
Mukund Thakur commented on HADOOP-18296:
----------------------------------------
{quote}Mukund, do we actually need to coalesce ranges on local fs reads?
because it is all local. we can just push out a list of independent regions.
{quote}
We are not merging during default vectored read and Raw local FS read
implementation. Although we are merging during the checksum FS.
{quote}we do still need to deal with failures by adding the ability to return
buffers to any pool on failure.
{quote}
if the read failed for any range, future.get() will throw an exception, and
thus the caller can return it to the pool. As per the design, the management of
buffers in a pool is being handled by the caller of API.
> Memory fragmentation in ChecksumFileSystem Vectored IO implementation.
> ----------------------------------------------------------------------
>
> Key: HADOOP-18296
> URL: https://issues.apache.org/jira/browse/HADOOP-18296
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: common
> Affects Versions: 3.4.0
> Reporter: Mukund Thakur
> Priority: Minor
> Labels: fs
>
> As we have implemented merging of ranges in the ChecksumFSInputChecker
> implementation of vectored IO api, it can lead to memory fragmentation. Let
> me explain by example.
>
> Suppose client requests for 3 ranges.
> 0-500, 700-1000 and 1200-1500.
> Now because of merging, all the above ranges will get merged into one and we
> will allocate a big byte buffer of 0-1500 size but return sliced byte buffers
> for the desired ranges.
> Now once the client is done reading all the ranges, it will only be able to
> free the memory for requested ranges and memory of the gaps will never be
> released for eg here (500-700 and 1000-1200).
>
> Note this only happens for direct byte buffers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
