[jira] [Commented] (HBASE-8338) Latency Resilience; umbrella list of issues that will help us ride over bad disk, bad region, ec2, etc.

["Enis Soztutar (JIRA)" <ji...@apache.org>]

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

Enis Soztutar commented on HBASE-8338:
--------------------------------------

Related, there is this idea of opening two wal writers, and switching to the other one, if we run into slowness, which is mentioned in the Bigtable paper. Do we have a jira for something similar? It might be addressed at multi-wal as well. 
                
> Latency Resilience; umbrella list of issues that will help us ride over bad disk, bad region, ec2, etc.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-8338
>                 URL: https://issues.apache.org/jira/browse/HBASE-8338
>             Project: HBase
>          Issue Type: Umbrella
>          Components: LatencyResilience
>            Reporter: stack
>            Priority: Critical
>
> Chatting w/ Elliott, we started listing out items to fix that would help keep hbase latency approximately constant as disks went bad, were saturated by a neighbour (ec2), etc.
> I must made a new LatencyResilience issue category to tag issues that contribute to this project.
> I have to go at moment but when I get back I'll start to link in existing issues that help this project along and I'll file new ones.
> Here is what we chatted about:
> + Multiple WALs effort will help keep write latency roughly constant.
> + Figuring how to get a new read started over dfsclient if current replica read is taking too long would help keep reads about constant (maybe could exploit the nkeywal hackery messing w/ replicas order).
> + There is an issue where client can currently pile up on a single region because of the way we do client queues by regionserver.  This needs fixing.
> The above are few ideas worth further exploration at least.
> Idea is to try and bring down our 95percentiles and to make us more robust in the face of dying disks, etc.  I see this issue rising to the fore now there has been good progress on the MTTR project.

--
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