[
https://issues.apache.org/jira/browse/HBASE-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-16046:
--------------------------
Description:
Our current rpc scheduler default is FIFO. Good for speed but as soon as the
server gets overloaded, our behavior goes south. We can do better, or a plan is
better than none. Our FB brothers and sisters added an rpc scheduler that is
smarter around overloading over in HBASE-15136. The implementation is the
codification of FIFO when all is dandy flipping to LIFO with CoDel and load
shedding when under duress. The algorithm is used elsewhere at FB w/ a nice
writeup on why it 'works' and why. Makes sense to me. Has nice feature that
tuning knobs are few and we should be able to nail defaults easy enough that
will work for majority of cases. Lets adopt it as our default going forward.
This is an umbrella issue for enabling it in 2.0.0. We need to do a few things
as subissues. The mighty [~mantonov] and crew want to get some production
experience first w/ their particular implementation -- makes sense -- and we
need to add the speedup from HBASE-16023 (currently the codel scheduler is much
slower than our default). Another consideration for here or as a follow on is
the suggestion that when all is running smooth, let the Reader thread run the
request rather than do handoff to handler (From [~ikeda] over on HBASE-14479)
was:
Our current rpc scheduler default is FIFO. Good for speed but as soon as the
server gets overloaded, our behavior goes suboptimal. We can do better. Our FB
brothers and sisters added over in an rpc scheduler that is smarter around
overloading over in HBASE-15136. The implementation is the codification of FIFO
when all is dandy flipping to LIFO with CoDel and load shedding when under
duress. The algorithm is used elsewhere at FB w/ a nice writeup on why it
'works'. Makes sense to me. Has nice feature that tuning knobs are few and we
should be able to nail defaults easy enough that will work for majority of
cases. Lets adopt it as our default going forward.
This is an umbrella issue for enabling it in 2.0.0. We need to do a few things
as subissues. The mighty [~mantonov] and crew want to get some production
experience first w/ their particular implementation -- makes sense -- and we
need to add the speedup from HBASE-16023 (currently the codel scheduler is much
slower than our default). Another consideration for here or as a follow on is
the suggestion that when all is running smooth, let the Reader thread run the
request rather than do handoff to handler (From [~ikeda] over on HBASE-14479)
> [UMBRELLA] Make our default rpc scheduler the adaptive LIFO+CoDel added in
> HBASE-15136
> --------------------------------------------------------------------------------------
>
> Key: HBASE-16046
> URL: https://issues.apache.org/jira/browse/HBASE-16046
> Project: HBase
> Issue Type: Task
> Components: rpc
> Reporter: stack
> Priority: Critical
> Fix For: 2.0.0
>
>
> Our current rpc scheduler default is FIFO. Good for speed but as soon as the
> server gets overloaded, our behavior goes south. We can do better, or a plan
> is better than none. Our FB brothers and sisters added an rpc scheduler that
> is smarter around overloading over in HBASE-15136. The implementation is the
> codification of FIFO when all is dandy flipping to LIFO with CoDel and load
> shedding when under duress. The algorithm is used elsewhere at FB w/ a nice
> writeup on why it 'works' and why. Makes sense to me. Has nice feature that
> tuning knobs are few and we should be able to nail defaults easy enough that
> will work for majority of cases. Lets adopt it as our default going forward.
> This is an umbrella issue for enabling it in 2.0.0. We need to do a few
> things as subissues. The mighty [~mantonov] and crew want to get some
> production experience first w/ their particular implementation -- makes sense
> -- and we need to add the speedup from HBASE-16023 (currently the codel
> scheduler is much slower than our default). Another consideration for here or
> as a follow on is the suggestion that when all is running smooth, let the
> Reader thread run the request rather than do handoff to handler (From
> [~ikeda] over on HBASE-14479)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
