hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (Jira)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-22850) Optimise lock acquisition in TxnHandler
Date Fri, 14 Feb 2020 23:26:00 GMT

    [ https://issues.apache.org/jira/browse/HIVE-22850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17037355#comment-17037355
] 

Hive QA commented on HIVE-22850:
--------------------------------



Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12993445/HIVE-22850.6.patch

{color:red}ERROR:{color} -1 due to no test(s) being added or modified.

{color:green}SUCCESS:{color} +1 due to 17993 tests passed

Test results: https://builds.apache.org/job/PreCommit-HIVE-Build/20628/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/20628/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-20628/

Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}

This message is automatically generated.

ATTACHMENT ID: 12993445 - PreCommit-HIVE-Build

> 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,
HIVE-22850.6.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)

Mime
View raw message