[
https://issues.apache.org/jira/browse/HDFS-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406668#comment-13406668
]
Matthew Jacobs commented on HDFS-3170:
--------------------------------------
Thanks, Todd. I didn't know about TimeUnit.convert in Java, that's a better way
to to the conversions.
Regarding switching to microseconds, I don't really have a strong opinion, but
I'm more used to seeing nanoseconds and milliseconds than microseconds in the
context of timing, even though the high resolution timer resolution is likely
only in microseconds anyway. Also, given that there are other metrics in
nanoseconds, I think it would be better just to be consistent. I'm happy to
change this if you'd prefer microseconds, though.
bq. In the case it's triggered, shouldn't we add an RTT=0 to the metric?
My thought was that getting a negative number really shouldn't happen because
the ack enqueue timestamp is taken before the actual packet send and the ack
recv timestamp is taken after the packet is received, so getting a downstream
ack duration must be strictly less than (or equal, though unlikely) to the
(ackRecv-ackEnqueue) duration unless something is wrong, because logically it
shouldn't happen. If something is wrong, reporting 0 seems like a guess to me
and I'd rather not report anything but would prefer to just log the issue
instead. I might be missing something though, what do you think?
I'll change fsync and will rename ackEnqueueTimeNanos.
> Add more useful metrics for write latency
> -----------------------------------------
>
> Key: HDFS-3170
> URL: https://issues.apache.org/jira/browse/HDFS-3170
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: data-node
> Affects Versions: 2.0.0-alpha
> Reporter: Todd Lipcon
> Assignee: Matthew Jacobs
> Attachments: hdfs-3170.txt, hdfs-3170.txt
>
>
> Currently, the only write-latency related metric we expose is the total
> amount of time taken by opWriteBlock. This is practically useless, since (a)
> different blocks may be wildly different sizes, and (b) if the writer is only
> generating data slowly, it will make a block write take longer by no fault of
> the DN. I would like to propose two new metrics:
> 1) *flush-to-disk time*: count how long it takes for each call to flush an
> incoming packet to disk (including the checksums). In most cases this will be
> close to 0, as it only flushes to buffer cache, but if the backing block
> device enters congested writeback, it can take much longer, which provides an
> interesting metric.
> 2) *round trip to downstream pipeline node*: track the round trip latency for
> the part of the pipeline between the local node and its downstream neighbors.
> When we add a new packet to the ack queue, save the current timestamp. When
> we receive an ack, update the metric based on how long since we sent the
> original packet. This gives a metric of the total RTT through the pipeline.
> If we also include this metric in the ack to upstream, we can subtract the
> amount of time due to the later stages in the pipeline and have an accurate
> count of this particular link.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
