hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Booth (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-918) Use single Selector and small thread pool to replace many instances of BlockSender for reads
Date Fri, 29 Jan 2010 19:32:34 GMT

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

Jay Booth commented on HDFS-918:

I'll definitely perform lots of benchmarking before asking for more of a formal review for
commit.  To be clear, this patch by itself doesn't open up any additional ports/services and
attempts minimal change to existing code -- the only major change is in opRead on DataXCeiver,
replacing creation/execution of a BlockSender with a quick call to register() on my new readserver
class (which should probably be renamed to MultiplexedBlockSender or something since it's
not actually a server, doesn't expose any new services).  The other changes are just the addition
of 3 new classes.  My newest patch is still at home and I'll upload it this weekend when I
have some time, the current patch here doesn't completely work.  

Right now I expect this to yield some pretty decent savings in CPU time but maybe not in wall-clock
time.  I'm thinking about 2 approaches, running datanode with time while performing a bunch
of IO tasks and checking CPU usage afterwards, and then measuring total throughput in TestDFSIO
on an oversubscribed cluster so that we get CPU-bound and can demonstrate improvement that
way.  Any preference?  Other suggestions?  I'm a little worried that simply timing datanode
will measure things like, how long I waited after start to launch a job, or background replication..
 but I suppose those problems exist with any measurement.

Also, I'm planning to add a parameter to configure usage of BlockSender vs MultiplexedBlockSender,
does "dfs.datanode.multiplexReads=true" sound good?

> Use single Selector and small thread pool to replace many instances of BlockSender for
> --------------------------------------------------------------------------------------------
>                 Key: HDFS-918
>                 URL: https://issues.apache.org/jira/browse/HDFS-918
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: data-node
>            Reporter: Jay Booth
>             Fix For: 0.22.0
>         Attachments: hdfs-multiplex.patch
> Currently, on read requests, the DataXCeiver server allocates a new thread per request,
which must allocate its own buffers and leads to higher-than-optimal CPU and memory usage
by the sending threads.  If we had a single selector and a small threadpool to multiplex request
packets, we could theoretically achieve higher performance while taking up fewer resources
and leaving more CPU on datanodes available for mapred, hbase or whatever.  This can be done
without changing any wire protocols.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message