[
https://issues.apache.org/jira/browse/HDFS-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404350#comment-13404350
]
Andy Isaacson commented on HDFS-3170:
-------------------------------------
{quote}
Can you use System.nanoTime so that it's (a) a monotonic clock instead of
time-of-day, and (b) higher granularity than MS? I think a lot of these metrics
will end up sub-millisecond.
{quote}
You may want to review hdfs/server/common/Util.java:monotonicNow, although it
returns milliseconds rather than ns.
{quote}
They're not super expensive, but they are syscalls, so let's be efficient and
call it the minimal number of times.
{quote}
{{clock_gettime}} is a vsyscall, so it's really pretty cheap. Looks like about
60 ns or 180 clock cycles for CLOCK_MONOTONIC (tested on Xeon X5670, 3GHz).
(Interestingly CLOCK_MONOTONIC_RAW which I expected to be faster by skipping
the adjustment, is actually slower at 240 ns on the same Xeon.)
> 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
>
>
> 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
