合理设置servicecomb.rest.server.thread-count的值

最新推荐文章于 2023-06-02 20:50:05 发布

原创

最新推荐文章于 2023-06-02 20:50:05 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#servicecomb #cse

ServiceComb SDK默认的servicecomb.rest.server.thread-count为1可能导致CPU利用率低，实际含义是垂直实例数量。该配置与操作系统资源绑定，大于CPU核数无意义。 Vertx使用少量线程池处理高并发，而增加servicecomb.rest.client.thread-count可分配更多连接资源。举例说明，CPU数为2时，不同thread-count配置如何影响eventloop和垂直实例。

很对开发者测试的时候，发现CSE SDK的CPU占用率很多时候只能够到1CPU，这是因为servicecomb.rest.server.thread-count默认值为1。官网文档将这个配置项含义解释为“服务端线程数”（参考： https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/protocol/rest-over-vertx.html），这个解释其实不怎么准确，容易和event-loop线程数混淆，开发者理解不了，而且提升这个值，CPU的利用率确实会增加，但是通过jstack查看线程数，却不会增加。

servicecomb.rest.server.thread-count实际上的含义是Vertical的一个概念： vertical instances count。他是一个非常抽象的概念，涉及到资源分配和线程绑定关系。比如当值为1的时候，服务端每收到一个请求，就会将请求丢到一个event-loop线程去执行，然后这个绑定关系就确定下来了，不会发生改变。

单纯的从服务端来看，缺省值为1，而event-loop线程是2 * CPU个，无法修改，那么实际上被使用的event-loop线程只有1个，其他线程都是永远空缺着的。 vertical instances count和操作系统资源是紧密绑定的，对于服务端而言，CPU核数就是资源，因此servicecomb.rest.server.thread-count大于CPU核数就显得毫无意义了。

但是操作系统还有其他的资源和处理，一个进程里面还会处理客户端网络调用， servicecomb.rest.client.thread-count增加，会分配更多的连接资源（句柄）。客户端的一个vertical instance和服务端一样，绑定到一个event-loop线程执行，不会改变。

Vertx就是利用了极小的线程池（2 * CPU），处理大量的并发请求（网络适配器、CPU、磁盘等）。着也就理解了为什么通常event-loop线程数固定不变，但是单纯看一个点，存在线程池冗余的情况。总体来看，线程池是被合理的利用到其他地方了。