[
https://issues.apache.org/jira/browse/HIVE-22850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Balamohan updated HIVE-22850:
------------------------------------
Description:
With concurrent queries, time taken for lock acquisition increases
substantially. As part of lock acquisition in the query,
{{TxnHandler::checkLock}} gets invoked. This involves getting a mutex and
compare the locks being requested for, with that of existing locks in
{{HIVE_LOCKS}} table.
With concurrent queries, time taken to do this check increase and this
significantly increases the time taken for getting mutex for other threads (due
to select for update). In a synthetic workload, it was in the order of 10+
seconds. This codepath can be optimized when all lock requests are SHARED_READ.
!Screenshot 2020-02-07 at 4.14.51 AM.jpg|width=743,height=348!
was:
With concurrent queries, time taken for lock acquisition increases
substantially. As part of lock acquisition in the query,
{{TxnHandler::checkLock}} gets invoked. This involves getting a mutex and
compare the locks being requested for, with that of existing locks in
{{HIVE_LOCKS}} table.
With concurrent queries, time taken to do this check increase and this
significantly increases the time taken for getting mutex for other threads (due
to select for update). In a synthetic workload, it was in the order of 10+
seconds. This codepath can be optimized when all lock requests are SHARED_READ.
> Optimise lock acquisition in TxnHandler
> ---------------------------------------
>
> Key: HIVE-22850
> URL: https://issues.apache.org/jira/browse/HIVE-22850
> Project: Hive
> Issue Type: Improvement
> Components: Hive
> Reporter: Rajesh Balamohan
> Priority: Major
> Attachments: HIVE-22850.1.patch, Screenshot 2020-02-07 at 4.14.51
> AM.jpg
>
>
> With concurrent queries, time taken for lock acquisition increases
> substantially. As part of lock acquisition in the query,
> {{TxnHandler::checkLock}} gets invoked. This involves getting a mutex and
> compare the locks being requested for, with that of existing locks in
> {{HIVE_LOCKS}} table.
> With concurrent queries, time taken to do this check increase and this
> significantly increases the time taken for getting mutex for other threads
> (due to select for update). In a synthetic workload, it was in the order of
> 10+ seconds. This codepath can be optimized when all lock requests are
> SHARED_READ.
>
>
> !Screenshot 2020-02-07 at 4.14.51 AM.jpg|width=743,height=348!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
