[jira] [Commented] (ASTERIXDB-1147) ConcurrentLockManager's performance bug when there are many locks on a single resource, such as dataset level lock

["Till Westmann (JIRA)" <ji...@apache.org>]

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

Till Westmann commented on ASTERIXDB-1147:
------------------------------------------

Looking at the code the tryLock on the dataset should cache the lock and not require a new lock every time.
And the instantTryLock for the entity should never create a request slot.

[~kisskys] Did you see the creation and release of all those dataset locks when running?

> ConcurrentLockManager's performance bug when there are many locks on a single resource, such as dataset level lock
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERIXDB-1147
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1147
>             Project: Apache AsterixDB
>          Issue Type: Bug
>            Reporter: Young-Seok Kim
>            Assignee: Till Westmann
>
> If a query scan a dataset which includes 1M records, the scan operator acquires 1M instantTryLocks. 
> Internally, ConcurrentLockManager holds 1M tryLocks in dataset level and 1M instantTryLocks in entity level. In other words, 1M dataset level locks are not released until the job is over. 
> If this situation happens, ConcurrentLockManager allocates 1M lockRequestSlots during lock acquiring phase and those slots are maintained in a linked list. Thus, when the job is over, those slots for the dataset level locks are released one at a time by searching each slot for each dataset level lock held by scanning the linked list. Thus, 1M slots of linked list is scanned 1M times. This is killing the scan performance. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)