[
https://issues.apache.org/jira/browse/HBASE-11208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14004936#comment-14004936
]
Nicolas Liochon commented on HBASE-11208:
-----------------------------------------
BTW, by changing this on a YCSB load test, I divided the max latency by 3 (from
45s to 15s). HBASE-11226 adds another division by 3, and this leads us in 5s
max latency. YMMV (obviously), but I like what I'm seeing here :-)
> Remove the hbase.hstore.blockingStoreFiles setting
> --------------------------------------------------
>
> Key: HBASE-11208
> URL: https://issues.apache.org/jira/browse/HBASE-11208
> Project: HBase
> Issue Type: Brainstorming
> Components: Compaction, regionserver
> Affects Versions: 0.99.0
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
>
> It's a little bit of a provocation, but the rational is:
> - there are some bugs around the delayed flush. For example, if the periodic
> scheduler has asked for a delayed flush, and that we need to flush, we will
> have to wait
> - if the number of WAL files increases, we won't flush immediately if the
> blockingFile number has been reached. This impacts the MTTR.
> - We don't write to limit the compaction impact, but they are many cases
> where we would want to flush anyway, as the writes cannot wait.
> - this obviously leads to huge write latency peaks.
> So I'm questioning this setting, it leads to multiple intricate cases,
> unpredictable write latency, and looks like a workaround for compaction
> performances. With all the work done on compaction, I think we can get rid of
> it. A solution in the middle would be to deprecate it and to set it to a
> large value...
> Any opinion before I shoot :-) ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
