[
https://issues.apache.org/jira/browse/HBASE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270801#comment-13270801
]
stack commented on HBASE-5898:
------------------------------
Can you do a test where much lower hit ratio? Any way to compare the amount of
'work' done by the cache or how latency is effected? I'm wondering if you can
use your tool to simulate the below:
{quote}
The downside is that for a workload with a lower cache hit ratio, we'll ask the
cache twice for every cache miss instead of just once. So we should see what
the performance difference is for something like a 10MB cache with 1GB dataset,
where the dataset fits in the OS buffer cache.
{quote}
If you can't, is it something you should make it measure?
> Consider double-checked locking for block cache lock
> ----------------------------------------------------
>
> Key: HBASE-5898
> URL: https://issues.apache.org/jira/browse/HBASE-5898
> Project: HBase
> Issue Type: Improvement
> Components: performance
> Affects Versions: 0.94.1
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Attachments: 5898-TestBlocksRead.txt, hbase-5898.txt
>
>
> Running a workload with a high query rate against a dataset that fits in
> cache, I saw a lot of CPU being used in IdLock.getLockEntry, being called by
> HFileReaderV2.readBlock. Even though it was all cache hits, it was wasting a
> lot of CPU doing lock management here. I wrote a quick patch to switch to a
> double-checked locking and it improved throughput substantially for this
> workload.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
