开个主题讨论下线程池参数自适应调整的可能性

2022-04-24 14:49:16 +08:00
 yanhomlin

开个主题讨论下线程池参数自适应调整的可能性

目前动态线程池开源框架 DynamicTp 是基于配置中心实现线程池参数调整的,有没有可能根据 cpu 、负载等指标自动调整(估计也是个大概,肯定不准)

以下是前几天发在 V 站上关于 DynamicTp 的介绍文章

美团动态线程池实践思路,开源了

美团动态线程池实践思路开源项目( DynamicTp ),线程池源码解析及通知告警篇

1694 次点击
所在节点    程序员
12 条回复
smilekung
2022-04-24 15:02:43 +08:00
在容器化这么流行的情况下,没必要对线程池进行自适应整定吧,如果负载上涨,降低线程池大小,一方面是不好测算具体值,一方面也可能对业务造成影响呀
还不如依靠容器平台的自动伸缩,负载或者请求量变化自动创建合适的容器数量
chendy
2022-04-24 15:10:38 +08:00
1 楼+1
动态扩缩线程池的使用场景是什么呢?……
golangLover
2022-04-24 15:17:02 +08:00
@chendy 一般人应该用不上吧,始终不都是美团这样的公司
rrfeng
2022-04-24 15:19:39 +08:00
任何 pool 都可以自动调整啊,无非是从设定 pool 固定大小变成了 pool 的「最多空闲」「最长空闲时间」「最小」和「最大」而已……

楼上说得对,要看具体有没有实践意义…
golangLover
2022-04-24 15:21:44 +08:00
不过虽然如此。但是学习楼主的代码我觉得还是有获益的。另外就是令我接触到大公司的编程思想。谢谢楼主
yanhomlin
2022-04-24 15:35:18 +08:00
@smilekung 必要性因人而异吧,毕竟还是有很多公司系统没有这种快速扩缩的能力,而且这也是两个不同维度,线程池更多偏重单机处理能力。这个问题也是使用 DynamicTp 框架的用户提出的,我觉得还是有一定探讨性的,比如系统负载不高的情况下,线程池负载比较高,是不是可以考虑调大下线程池参数;反之,系统负载高的情况下,一般也是由于线程过多造成,就可以考虑调小下线程池参数。但是就像你说的,很难把控具体值。
yanhomlin
2022-04-24 15:38:54 +08:00
@rrfeng 意义我觉得还是有的,但是自动调整,具体数值不好把控,没有一个比较成熟的最简实践算法支持
yanhomlin
2022-04-24 15:39:19 +08:00
@golangLover 谢谢你
akira
2022-04-25 11:39:18 +08:00
挺有意思的。 如果判断准确的话,线程参数不需要用户调整,也可以获得 90 分以上的效果了。

一般情况下,大部分软件部署的时候,都需要人工针对目标服务器的配置,进行一些经验性的参数调整,才能更好发挥服务器性能,而普通用户其实很多时候是很难完全搞懂这些参数的。
如果大部分参数都能动态的自动调整,那对于普通用户,世界会美好很多。
lesismal
2022-04-25 12:09:29 +08:00
楼主上一个帖子我忍住了没好意思说,这个帖子还是说下吧:

何不用 go?
lesismal
2022-04-25 12:11:39 +08:00
我们一些服务用 go 替换 java 后,内存消耗普遍降低了 50+%、个别服务占用降低 70%,cpu 消耗降低了 30-70%不等
wolfie
2022-04-26 16:44:10 +08:00
@lesismal #11
确定不是重构时候优化了一下代码吗。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/848935

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX