[ 
https://issues.apache.org/jira/browse/PHOENIX-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani reassigned PHOENIX-7432:
-------------------------------------

    Assignee: Viraj Jasani

> 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
>            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)

Reply via email to