odraese commented on a change in pull request #633: HIVE-21740: Collect LLAP
execution latency metrics
URL: https://github.com/apache/hive/pull/633#discussion_r285714898
##########
File path:
llap-tez/src/java/org/apache/hadoop/hive/llap/tezplugins/metrics/LlapTaskSchedulerMetrics.java
##########
@@ -276,6 +302,43 @@ private void getTaskSchedulerStats(MetricsRecordBuilder
rb) {
.addCounter(SchedulerPendingPreemptionTaskCount,
pendingPreemptionTasksCount.value())
.addCounter(SchedulerPreemptedTaskCount, preemptedTasksCount.value())
.addCounter(SchedulerCompletedDagCount, completedDagcount.value());
+ daemonTaskLatency.forEach((k, v) -> rb.addGauge(v, v.getMean()));
+ }
+
+ static class DaemonLatencyMetric implements MetricsInfo {
+ private String name;
+ private ExponentiallyDecayingReservoir reservoir;
Review comment:
What is the benefit of using am exponential decay here, vs. simple sliding
window (i.e. guava stats)? Specifically with the low amount of entries (right
now 1028), a few more recent task execution times can have a huge impact on
what we believe is the node's average over a longer period of time. The whole
idea of using the average here is to smooth out the task execution times across
a larger amount of tasks. I have the fear, that the exponential decay is
contradicting this by giving few, very recent values, a high impact.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
