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

Arpit Agarwal reassigned HDDS-2324:
-----------------------------------

    Target Version/s: 0.6.0
            Assignee: Rakesh Radhakrishnan  (was: Nanda kumar)
              Labels: Triaged performance  (was: performance)
            Priority: Critical  (was: Major)

We need to revisit this for 0.6.0. Some of the changes done as part of 
HDDS-2939 should have alleviated this performance problem. I believe [~rakeshr] 
is already looking into validating this.

> Enhance locking mechanism in OzoneMangaer
> -----------------------------------------
>
>                 Key: HDDS-2324
>                 URL: https://issues.apache.org/jira/browse/HDDS-2324
>             Project: Hadoop Distributed Data Store
>          Issue Type: Bug
>          Components: Ozone Manager
>            Reporter: Rajesh Balamohan
>            Assignee: Rakesh Radhakrishnan
>            Priority: Critical
>              Labels: Triaged, performance
>         Attachments: om_lock_100_percent_read_benchmark.svg, 
> om_lock_reader_and_writer_workload.svg
>
>
> OM has reentrant RW lock. With 100% read or 100% write benchmarks, it works 
> out reasonably fine. There is already a ticket to optimize the write codepath 
> (as it incurs reading from DB for key checks).
> However, when small amount of write workload (e.g 3-5 threads) is added to 
> the running read benchmark, throughput suffers significantly. This is due to 
> the fact that the reader threads would get blocked often.  I have observed 
> around 10x slower throughput (i.e 100% read benchmark was running at 12,000 
> TPS and with couple of writer threads added to it, it goes down to 1200-1800 
> TPS).
> 1. Instead of single write lock, one option could be good to scale out the 
> write lock depending on the number of cores available in the system and 
> acquire relevant lock by hashing the key.
> 2. Another option is to explore if we can make use of StampedLocks of JDK 
> 8.x, which scales well when multiple readers and writers are there. But it is 
> not a reentrant lock. So need to explore whether it can be an option or not.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to