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)