[
https://issues.apache.org/jira/browse/FLINK-32954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-32954:
-----------------------------------
Labels: pull-request-available (was: )
> Metrics expose number of heap timer
> -----------------------------------
>
> Key: FLINK-32954
> URL: https://issues.apache.org/jira/browse/FLINK-32954
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Metrics, Runtime / State Backends
> Reporter: Rui Xia
> Assignee: Rui Xia
> Priority: Major
> Labels: pull-request-available
>
> Expose the current number of heap timers to metric reporter. Internally,
> expose the size of `InternalPriorityQueue` to `MetricGroup`.
>
> This metric can aid in debugging the memory consumption of heap timer.
> Currently, we need to dump jvm heap to identify the memory consumption of
> heap timer. With this metric, users can quickly get a basic knowledge on the
> working condition of heap timers.
>
> The *numOfTimers* metric is only suitable for heap timer. Heap priority queue
> (`AbstractHeapPriorityQueue`) has an off-the-shelf member to get size
> (`AbstractHeapPriorityQueue#size`). Expose it to metric reporter is zero-cost.
>
> The *numOfTimers* metric for RocksDB timer brings performance loss, and is
> not supported right now. RocksDB (cached) priority queue does *not* has an
> off-the-shelf member to get size. Intuitively, we can add an exclusive
> counter for RocksDB priority queue. This counter affects the runtime
> per-record code path. Thus, the *numOfTimers* metric for RocksDB timer is
> currently not supported. I think there may exist some better/lightweight
> metrics to let user learn the work condition of RocksDB timers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
