如何设置Hystrix线程池大小

作者: 编程技术  发布:2019-09-23

背景介绍

JSF(京东服务框架,类似dubbo)默认配置了可伸缩的最大到200的工作线程池,每一个向外提供的服务都在其中运行,这些服务内部调用外部依赖时一般是同步调用,不单独限制调用并发量,因为同步调用时会阻塞原服务线程,因此实际上所有外部调用共享了JSF的200工作线程池。

Hystrix框架为了隔离依赖相互影响,默认使用了线程隔离机制,为每个依赖提供一个小的线程池,如果该线程池已满新的调用将被立即拒绝,默认不排队加快失败返回。这与JSF原来的机制非常不一样,我们的问题是:

  1. 额外的线程池是否有太大的性能开销?

  2. 线程池大小设置多少合理?

希望通过本次测试调研得到答案。

在压测FeignClient接口时候,发现FeignClient接口处理请求的能力和Hystrix为其提供的线程池大小有关。

用例介绍

构造两个接口,分别调用原生mock方法和调用经过hystrix包装的mock方法,两个mock方法内部都是一个Thread.sleep,根据不同参数模拟不同性能的外部依赖调用。其中JSF线程池为默认值最大200,hystrix单个线程池大小为默认值10,默认超时1000ms,为了排除干扰禁用断路器。根据两个接口、不同mock参数和不同压测线程数组合构造出共11个测试用例。

部署单台只包括这两个接口的生产机器,使用分布式压测平台对其进行压测,主要通过接口内部的UMP进行性能和JVM状态监控,JVM使用JDK8并且开启G1收集器(压测中无full gc)。

@Servicepublic class MockJsfServiceRef {    @HystrixCommand(commandProperties = {            @HystrixProperty(name = "circuitBreaker.enabled", value = "false")    })    public String doHystrix(Integer param) throws Exception {        Thread.sleep;        return "1";    }    public String doNative(Integer param) throws Exception {        Thread.sleep;        return "1";    }}

测试代码:

压测数据及解析

图片 1

首先前8个用例和结果数据体现了在相同的正常压力下不同调用方式和不同性能依赖的吞吐量和性能指标,可以看出:

  1. 同样耗时依赖条件下,hystrix会占用更多的cpu资源,但是并不显著,并且当耗时增加时该影响持续减小(由于压测接口无任何计算逻辑因此整体cpu使用很低,推测实际服务逻辑耗费CPU较多时hystrix的性能影响更不明显,有待生产环境验证)。

  2. 相同的压测线程(hystrix处理线程也是10)下依赖耗时以及与之对应的平均耗时avg直接影响了接口的吞吐量(rps,每秒请求数)。观察该规律可以得到公式:threads / avg = rps,下面举例:

    • avg=320时,10 / 0.32 = 31.25,观察用例7,8分别得到原生30.2和hystrix的30.3,基本吻合。

    • avg=80时,10 / 0.08 = 125,观察用例5,6分别得到原生120.4和hystrix的120.1,有所损耗后吻合。

    • avg=20时,10 / 0.02 = 500,观察用例3,4分别得到原生456.6和hystrix的454.4,损耗增加。

    • avg=5时,10 / 0.005 = 2000,观察用例1,2分别得到原生1536.4和hystrix的1521.4,损耗较大。

  3. 其他信息:从上面数据也可以看出当rps增加到较高时线程调度本身带来的损耗增加显著,CPU使用率也显著上升,即线程调度压力开始显著增加,无论是否使用hystrix这都是无法避免。hystrix在相同耗时对比中增加部分cpu使用率,对max指标有所影响,个别数据下对tp999也有所影响,但是影响都比较小。

后面三组测试用例则继续提高压测线程,由于hystrix默认配置10个线程,因此当压测超过10个线程时,多出来的请求则会处理不过来,体现为线程池满后直接拒绝,快速返回失败,同时快速返回后压测端又会立刻请求,结果就是rps迅速上升同时成功率急速下降,线程池正常处理的请求则未受影响,用例9体现了这一现象(服务端监控avg=320而客户端由于大量1ms的快速失败返回使avg=14)。

用例10和11是原生调用,我们继续提高压测线程到200和201,以期测试JSF的200线程池,得到结果符合预期,即JSF线程被打满后无法处理额外的请求,与用例9表现相似,但是临界值从10线程到200线程,更多的线程带来了更多吞吐量。还有一点不同的细节在于,hystrix线程满后返回异常时可以触发我们的UMP监控,捕捉到成功率下降,但是JSF线程池满后,直接拒绝请求,服务端无法监控到这些失败,只有调用端能得到成功率下降的信息。

@FeignClient (value="service-provider", fallbackFactory= providerServiceFallbackFactory.class)

public interface testService {

@RequestMapping(value="/v1/test",method= RequestMethod.POST)

Result test(@RequestBody TestEntity testEntity);

}

结论

通过上面压测数据解析,我们可以对开始的问题进行解答。

  1. 额外的线程池是否有太大的性能开销?

    上述测试中hystrix对性能损耗并不大,不管是CPU使用率的增加已经性能指标的影响都不明显,但是由于测试用例的局限性,不能说明所有情况,但我认为达到了到生产环境小范围使用的条件,可以通过继续积累使用经验解答该问题。

    The Netflix API processes 10+ billion HystrixCommand executions per day using thread isolation.

    Each API instance has 40+ thread-pools with 5-20 threads in each (most are set to 10).

  2. 线程池大小设置多少合理?

    我们在测试中得到了公式:threads / avg = rps,实际上hystrix的文档中也有一段类似的描述:

    requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room

    30 rps * 0.2 second = 6 + breaking room = 10 threads

    初看这段描述时难以理解,但是通过我们上面的压测数据和公式可以明了,它将avg替换为了tp99,同时再增加了更多余量,以期尽量避免正常流量增长和依赖波动导致线程池被打满的情况。

    举一个实际例子,小金库当前并发量最大的接口A,在去年双十一压测中达到了22.6W的RPS,一共有201台实例,单实例RPS=1124,tp99=6ms,以此计算 1124 * 0.006 = 6.7,因此增加余量到10即可满足需求。

  3. 新问题,线程池满了怎么办?

    在上面测试数据解析中,我们发现由于hystrix为每个依赖严格限制了一个小的线程池,当线程池满了后拒绝服务似乎影响很大。根据我们的公式threads = rps * avg,当流量过高时或依赖耗时增加过多时都会触发线程池打满。首先针对流量过高我们可以通过监控报警(主动增加线程数,可以动态配置生效) + 提前预设足够的余量解决。其次针对依赖耗时增加过多的问题,前面的做法也能部分解决该问题,但是回归起点来说,某个依赖突然变得非常慢,以至于打满JSF线程池造成应用整体不可用,这本来就是我们要用hystrix解决的问题,使用hystrix后故障依赖的调用快速失败,同时失败率积累到阈值后断路器熔断降级,在该依赖恢复后自动关闭断路器,恢复对其调用 。

并发测试后异常:

Task java.util.concurrent.FutureTask@27d69e27 rejected from java.util.concurrent.ThreadPoolExecutor@61d1c14e[Running, pool size = 10, active threads = 10, queued tasks = 0, completed tasks = 62058]

原因分析:

  1. 并发数太大,触发了熔断。

  2. 熔断原因和ThreadPoolExecutor有关,并且提示pool size是10,线程池满了,无法提交任务。

查看Hystrix官方文档:

Hystrix使用舱壁模式(bulkhead pattern)隔离每个依赖,从而限制对依赖的并发访问。

图片 2

客户端(库,网络请求等等)运行在不同的线程。这使它们独立于请求线程(Tomcat线程池),因此请求线程可以在依赖线程花费时间太长时,摆脱此依赖线程。

Hystrix为每个依赖提供一个小的线程池(或信号)(默认10个线程),如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。

图片 3

可以通过设置依赖线程池默认大小,提高并发处理能力。在application.yml里面:

hystrix:

   threadpool:

       service-provider:

           coreSize:  100

本文由贝博体育app发布于编程技术,转载请注明出处:如何设置Hystrix线程池大小

关键词: