Viraj Jasani created PHOENIX-7432:
-------------------------------------
Summary: 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
Reporter: Viraj Jasani
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)
