You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Denys Kuzmenko (Jira)" <ji...@apache.org> on 2020/02/13 15:42:00 UTC
[jira] [Issue Comment Deleted] (HIVE-22850) Optimise lock
acquisition in TxnHandler
[ https://issues.apache.org/jira/browse/HIVE-22850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Denys Kuzmenko updated HIVE-22850:
----------------------------------
Comment: was deleted
(was: [~rajesh.balamohan]: fyi https://issues.apache.org/jira/browse/HIVE-22888)
> 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, HIVE-22850.2.patch, HIVE-22850.3.patch, HIVE-22850.4.patch, Screenshot 2020-02-07 at 4.14.51 AM.jpg, jumpTableInfo.png
>
>
> 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)