[IMPALA-2684] Fragment start latencies reported in wrong unit

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: Impala 2.2.4
• Fix Version/s: Impala 2.5.0
• Component/s: Distributed Exec
• Target Version: Impala 2.5.0
• Assignee: Henry Robinson
• Reporter: Flume QA
• Created: 18/Nov/15 22:06
• Updated: 03/Feb/16 19:07
• Resolved: 03/Feb/16 19:07

Description

The metric Fragment start latencies is reported in nanoseconds:

Fragment start latencies: count: 39, last: 0.078961ns, min: 0.011105ns, max: 0.541386ns, mean: 0.375923ns, stddev: 0.124721ns

According to my research, and I am probably wrong, but I think it should be reported in seconds (or code which divides it's value by 1000 * 1000 * 1000 should be removed).

Coordinator uses MonotonicStopWatch here:

https://github.com/cloudera/Impala/blob/0849c12423dd790c4244566ef3882770222fa155/be/src/runtime/coordinator.cc#L108

which returns elapsed time in nanoseconds here:

https://github.com/cloudera/Impala/blob/0849c12423dd790c4244566ef3882770222fa155/be/src/util/stopwatch.h#L120

The problem occurs when elapsed time is converted to seconds here:

https://github.com/cloudera/Impala/blob/0849c12423dd790c4244566ef3882770222fa155/be/src/runtime/parallel-executor.cc#L54

despite the fact that the metric definition is already in nanoseconds here:

https://github.com/cloudera/Impala/blob/0849c12423dd790c4244566ef3882770222fa155/be/src/runtime/coordinator.cc#L405

Issue Links

• is related to: IMPALA-1599 Improve query start-up time with many fragment instances