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

Varun Sharma commented on HBASE-8836:
-------------------------------------

Hi,

We suffered from the same issue. However, in our case there were too many 
writes compared to reads. Basically the writes starved all the handlers, the 
reads as such executed fast but ended up getting queued. We really cared about 
the reads and so hacked a change to our HBase binary to build a separate pool 
for Get(s) (We do Gets for our reads). That improved the read latencies vastly 
- p99 went down from 500ms down to < 100ms. We did not raise a JIRA since we 
thought that the change would not be accepted.

This patch is very similar to what we are doing (a pool of GET Handlers with 
QoS annotations), so it would be great if this could be patched in.

Thanks
Varun

> Separate reader and writer thread pool in RegionServer, so that write 
> throughput will not be impacted when the read load is very high
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-8836
>                 URL: https://issues.apache.org/jira/browse/HBASE-8836
>             Project: HBase
>          Issue Type: New Feature
>          Components: Performance, regionserver
>    Affects Versions: 0.94.8
>            Reporter: Tianying Chang
>            Assignee: Tianying Chang
>             Fix For: 0.98.0
>
>         Attachments: hbase-8836.patch, Hbase-8836-perfNumber.pdf, 
> HBase-8836-QosAnotation.patch, threadPool-write-NoWAL.png, 
> threadPool-write-WithWAL.png
>
>
> We found that when the read load on a specific RS is high, the write 
> throughput also get impacted dramatically, and even cause write data loss 
> sometimes. We want to prioritize the write by putting them in a separate 
> queue from the read request, so that slower read will not make fast write 
> wait nu-necessarily long.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to