[
https://issues.apache.org/jira/browse/IMPALA-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quanlong Huang updated IMPALA-11409:
------------------------------------
Description:
Impala coordinator tracks local metrics of the catalog, e.g. number of
dbs/tables. When use_local_catalog is enabled, it also tracks the cache
metrics, e.g. cache hit/miss count/rate.
These metrics are updated at the end of each statement, even for simple
statements like "USE <db>", "SET var=xxx", "SELECT 1". The catalog update
thread will also update the metrics in the end.
https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L1272
https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L2065
These metrics are global metrics of the local catalog cache. They are not
specifit to a simple statement. It's a waste to update the metrics concurrently.
https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L1526-L1559
We've seen "hanging issues" that all statements, including the catalog update
thread, are slowly executing the UpdateCatalogMetrics() function. See details
in the attached jstack dump.
Indeed, if one thread is running the UpdateCatalogMetrics() function, the other
threads can skip it and move forward.
was:
Impala coordinator tracks local metrics of the catalog, e.g. number of
dbs/tables. When use_local_catalog is enabled, it also tracks the cache
metrics, e.g. cache hit/miss count/rate.
These metrics are updated at the end of each statement, even for simple
statements like "USE <db>", "SET var=xxx", "SELECT 1". The catalog update
thread will also update the metrics in the end.
These metrics are global metrics of the local catalog cache. They are not
specifit to a simple statement. It's a waste to update the metrics concurrently.
We've seen "hanging issues" that all statements, including the catalog update
thread, are slowly executing the UpdateCatalogMetrics() function. See details
in the attached jstack dump.
Indeed, if one thread is running the UpdateCatalogMetrics() function, the other
threads can skip it and move forward.
> Skip UpdateCatalogMetrics if another thead is on-going in it
> ------------------------------------------------------------
>
> Key: IMPALA-11409
> URL: https://issues.apache.org/jira/browse/IMPALA-11409
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Reporter: Quanlong Huang
> Assignee: Quanlong Huang
> Priority: Critical
> Attachments: jstack-1.txt
>
>
> Impala coordinator tracks local metrics of the catalog, e.g. number of
> dbs/tables. When use_local_catalog is enabled, it also tracks the cache
> metrics, e.g. cache hit/miss count/rate.
> These metrics are updated at the end of each statement, even for simple
> statements like "USE <db>", "SET var=xxx", "SELECT 1". The catalog update
> thread will also update the metrics in the end.
> https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L1272
> https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L2065
> These metrics are global metrics of the local catalog cache. They are not
> specifit to a simple statement. It's a waste to update the metrics
> concurrently.
> https://github.com/apache/impala/blob/bb610dee09a8069bb993b4c668f7e481c1774b70/be/src/service/impala-server.cc#L1526-L1559
> We've seen "hanging issues" that all statements, including the catalog update
> thread, are slowly executing the UpdateCatalogMetrics() function. See details
> in the attached jstack dump.
> Indeed, if one thread is running the UpdateCatalogMetrics() function, the
> other threads can skip it and move forward.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
