You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Chesnay Schepler (JIRA)" <ji...@apache.org> on 2019/04/05 12:01:00 UTC
[jira] [Updated] (FLINK-11887) Latency metrics drift apart
[ https://issues.apache.org/jira/browse/FLINK-11887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chesnay Schepler updated FLINK-11887:
-------------------------------------
Fix Version/s: (was: 1.8.1)
(was: 1.9.0)
1.8.0
> Latency metrics drift apart
> ---------------------------
>
> Key: FLINK-11887
> URL: https://issues.apache.org/jira/browse/FLINK-11887
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Metrics
> Affects Versions: 1.6.3
> Reporter: Suxing Lee
> Assignee: Suxing Lee
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.3, 1.8.0
>
> Attachments: flink_taskmanager_job_latency_source_id_operator_id_operator_subtask_index_1_latency.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The operator's latency time is increased by approximately 2.7 minutes per day (see the attached).
> We compute the latency by System.currentTimeMillis - marker.getMarkedTime.
> There is no guarantee that System.currentTimeMillis and System.nanoTime don't drift apart.
> If a GC pause or linux preemptive scheduling happenes, this should affect latency metrics.
> Latency metrics drift away from their initial values with time(verify this result via the JVM Heap Dump).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)