[
https://issues.apache.org/jira/browse/PHOENIX-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-7432:
----------------------------------
Affects Version/s: 5.2.0
> getTable for PHYSICAL_TABLE link should use common utility
> ----------------------------------------------------------
>
> Key: PHOENIX-7432
> URL: https://issues.apache.org/jira/browse/PHOENIX-7432
> Project: Phoenix
> Issue Type: Task
> Affects Versions: 5.2.0
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
>
> We have seen large GC spikes when some views under the same table -> view
> hierarchy get dropped concurrently. Upon analyzing in detail ([~jisaac]'s
> heap dump analysis), we found that multiple drop view threads are busy
> scanning the same table row for PHYSICAL_TABLE link. This recursive getTable
> is introduced by PHOENIX-6247 logical-physical table separation. We have also
> fixed a bug that has caused all active handlers on SYSTEM.CATALOG
> regionserver to get occupied due to recursive getTable call for view index
> table that does not exist in SYSTEM.CATALOG, we have fixed it with
> PHOENIX-7369.
> However, with the current analysis, it is clear that getTable is trying to
> scan large row for the given table (family name for the PHYSICAL_TABLE link).
> Specifically, multiple threads can hold large num of Cells if the row is
> bigger and this can mean that GC is not able to clean up some of these large
> objects as they are too many.
> We have found one noticeable difference b/ when recursive getTable() on
> physical link table and getTable() on given table tries to retrive PTable by
> scanning SYSTEM.CATALOG. getTable() uses a write lock to protect metadata
> cache update and by doing so it only allows single thread to scan
> SYSTEM.CATALOG for the given table entry (key: tenant id + schema name +
> table name). However, when recursive call to physical table link using
> getTable() has new implementation and it does not use any lock for the given
> table name and therefore multiple threads can scan SYSTEM.CATALOG rather than
> single thread doing it so that others can just get the object from metadata
> cache.
> The proposal of this Jira is to remove unnecessary getTable() internal
> implementation that tries to retrieve PTable object without any lock.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
