hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-9663) Optimize some RPC call using lighter weight construct than DatanodeInfo
Date Mon, 25 Jan 2016 12:19:39 GMT

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

Kai Zheng commented on HDFS-9663:

Wonder if it's good to output the protocol wire data size in logs, trace or metrics. The method
to compute the wire data size to send is very simple and adding no overhead.

[~cmccabe], would you have any comment on this? Thanks.

> Optimize some RPC call using lighter weight construct than DatanodeInfo
> -----------------------------------------------------------------------
>                 Key: HDFS-9663
>                 URL: https://issues.apache.org/jira/browse/HDFS-9663
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Kai Zheng
>            Assignee: Kai Zheng
> While working on HDFS-8430 when add a RPC in DataTransferProtocol, it was noticed the
very heavy construct either {{DatanodeInfo}} or {{DatanodeInfoWithStorage}} is used to represent
a datanode just for connection in most time. However, it's very fat and contains much more
information than that needed. See how it's defined:
> {code}
> public class DatanodeInfo extends DatanodeID implements Node {
>   private long capacity;
>   private long dfsUsed;
>   private long remaining;
>   private long blockPoolUsed;
>   private long cacheCapacity;
>   private long cacheUsed;
>   private long lastUpdate;
>   private long lastUpdateMonotonic;
>   private int xceiverCount;
>   private String location = NetworkTopology.DEFAULT_RACK;
>   private String softwareVersion;
>   private List<String> dependentHostNames = new LinkedList<>();
>   private String upgradeDomain;
> ...
> {code}
> In client and datanode sides, for RPC calls like {{DataTransferProtocol#writeBlock}},
looks like the information contained in {{DatanodeID}} is almost enough.
> I did a quick hack that using a light weight construct like {{SimpleDatanodeInfo}} that
simply extends DatanodeID (no other field added, but if whatever field needed, then just add
it) and changed the DataTransferProtocol#writeBlock call. Manually checked many relevant tests
it did work fine. How much network traffic saved, did a simple test with codes in {{Sender}}:
> {code}
>   private static void send(final DataOutputStream out, final Op opcode,
>       final Message proto) throws IOException {
>     LOG.trace("Sending DataTransferOp {}: {}",
>         proto.getClass().getSimpleName(), proto);
>     int before = out.size();
>     op(out, opcode);
>     proto.writeDelimitedTo(out);
>     int after = out.size();
>     System.out.println("XXXXXXXXXXXXXXXXX sent=" + (after - before));
>     out.flush();
>   }
> {code}
> Ran the test {{TestWriteRead#testWriteAndRead}}, the change can  save about 100 bytes
in most time for the call. The saving may be not so big because only 3 datanodes are to send,
but in situations like in {{BlockECRecoveryCommand}}, there can be 6+ 3 datanodes as targets
and sources to send, the saving will be significant.
> Hence, suggest use more light weight construct to represent a datanode in RPC calls when
possible. Or other ideas to avoid unnecessary wire data size. This may make sense, as noted,
there were some discussions in HDFS-8999 to save some datanodes bandwidth.

This message was sent by Atlassian JIRA

View raw message