[
https://issues.apache.org/jira/browse/HBASE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13758918#comment-13758918
]
Nicolas Liochon commented on HBASE-8836:
----------------------------------------
It's very interesting. Could you give some details on the issue itself?
You say: writes are getting slow because they have to wait for slow get. Could
it be that we cannot have a lot of threads writing because there is a single
WAL, so we should have 2 threads for writing, and the other for reading? How
does it work if the put don't write into the WAL for example?
I mean, if the operations have an immutable fixed time, whatever the order the
final throughput (time to execute all the operations) won't change. So I would
like to understand where you make the money here :-), and if it's a general
improvement or specific to a load (you seem to say it's for cheap puts,
expensive gets)
+1 to what Lars said as well on batch mutation and patch globally (it needs a
little bit of rework ;-) ).
Note that the implementation should be much easier to do in trunk because of
the pluggable scheduler.
As I said above, I think it's quite interesting, there is likely something to
improve here.
> 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: Nicolas Liochon
> Fix For: 0.98.0
>
> Attachments: hbase-8836.patch, Hbase-8836-perfNumber.pdf
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
