[
https://issues.apache.org/jira/browse/HBASE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838394#action_12838394
]
stack commented on HBASE-2180:
------------------------------
I was thinking of a very old issue, HADOOP-2341, but that was about CLOSE_WAIT,
not TIME_WAIT. Erik I presume the TIME_WAIT are on the datanode side? I
suppose there could be an issue here if many random reads in a short amount of
time and the minimum segment lifetime (MSL) time is long in your tcp/ip
implementation. Do you know what it is? 2minutes seems default reading up on
the internets so could be in TIME_WAIT for 4 minutes. This what you are seeing
you think Erik? They go away after a while? Whats the OS? This would seem
to be a new issue then. We need pread that does keep-alive reusing sockets
(Todd!).
> Bad random read performance from synchronizing hfile.fddatainputstream
> ----------------------------------------------------------------------
>
> Key: HBASE-2180
> URL: https://issues.apache.org/jira/browse/HBASE-2180
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: stack
> Fix For: 0.20.4, 0.21.0
>
> Attachments: 2180-v2.patch, 2180.patch
>
>
> deep in the HFile read path, there is this code:
> synchronized (in) {
> in.seek(pos);
> ret = in.read(b, off, n);
> }
> this makes it so that only 1 read per file per thread is active. this
> prevents the OS and hardware from being able to do IO scheduling by
> optimizing lots of concurrent reads.
> We need to either use a reentrant API (pread may be partially reentrant
> according to Todd) or use multiple stream objects, 1 per scanner/thread.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
