这是一个创建于 1130 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景：在指定时间内尽量请求多个服务的数据。使用线程池并发请求数据。
问题：核心线程数设置小了要等队列满了才加线程，队列小了缓冲不够大，队列大了，加线程要等太久；
核心线程数设置大了，可能太浪费，设置核心线程超时，设置大了也会导致前面的线程应超时销毁，后面的请求又一直创建线程。
解决思路：核心线程数开始设置最大线程数的一半，设置监测点：在核心线程超时销毁时，减小一半核心线程数，在队列达到现有线程数处理能力设定负载量时，增长一定比例核心线程数。核心线程数不能超过最大线程数。
大家觉得怎么样？
问题：核心线程数设置小了要等队列满了才加线程，队列小了缓冲不够大，队列大了，加线程要等太久；
核心线程数设置大了，可能太浪费，设置核心线程超时，设置大了也会导致前面的线程应超时销毁，后面的请求又一直创建线程。
解决思路：核心线程数开始设置最大线程数的一半，设置监测点：在核心线程超时销毁时，减小一半核心线程数，在队列达到现有线程数处理能力设定负载量时，增长一定比例核心线程数。核心线程数不能超过最大线程数。
大家觉得怎么样？
 |
1
guaguaguaxia1 2021-10-20 17:54:55 +08:00
美团技术团队的方法是把线程数做成可配置的，有问题后台改一下配置就好了
|
 |
2
dqzcwxb 2021-10-20 18:17:53 +08:00
https://v2ex.com/t/741974
没有算法,业务压测自己配 |
 |
3
22yune OP @guaguaguaxia1 这个是配合监控，人工计算再配置吧。我说的自适应算法是把这个过程程序化自动化。
|
 |
4
SoloCompany 2021-10-20 20:37:52 +08:00
用 SynchronousQueue 加一个备用队列, task reject 时才加入到备用队列
|
 |
5
chihiro2014 2021-10-20 23:28:33 +08:00
可以看看 Project Reactor 中 Scheduler 的设计方式？？和你说的类似
|
 |
6
546L5LiK6ZOt 2021-10-21 00:23:20 +08:00 via iPhone
既然核心线程数可以增加，为啥不一开始就配置跟最大线程数一样呢？核心线程数也可以设置空闲时间，晚一点销毁感觉对性能影响不大。感觉楼主提的方案对性能提升不大，当然还是实际测试下好。
线程池本质就是复用资源，资源有限。所以我觉得理想的自适应做法应该是想办法自动判断资源数量。例如说数据库连接池，你得想办法用程序来判断多少连接才是最好的。 |
 |
7
nl101531 2021-10-21 09:21:27 +08:00 via iPhone
因为有销毁机制，所以一般设置大一点没多大问题。不过在有些具备流量峰值的系统就挺有用的了，应对峰值可以迅速自动调整策略。这个可以作为一个通用能力。
|
 |
8
GrayXu 2021-10-21 09:30:49 +08:00
@546L5LiK6ZOt elasticity
|
|
9
546L5LiK6ZOt 2021-10-21 10:31:02 +08:00 via iPhone
我想到的一个方法是，监控 cpu 、内存利用率等系统指标。如果负载低，则增加线程数量。
|
 |
10
lidlesseye11 2021-10-21 10:34:56 +08:00
|
 |
11
notwaste 2021-10-21 16:14:15 +08:00
美团有给出可配置的方案，我比较关注拒绝策略的场景选择
|
 |
12
mawerss1 2021-10-21 23:13:28 +08:00 via iPhone
本质还是和任务的执行时长有关，线程数太高 cpu 占用上升，线程切换时间占用变高浪费 cpu 时间，线程数太低任务堆积最终响应时间变长，追求高响应应该直接拒绝执行报错，还是压测加机器
|
|
13
22yune OP @546L5LiK6ZOt 设置大了也会导致前面的线程应超时销毁，后面的请求又一直创建线程。这样的结果就是线程池基本没有用，线程一直在创建新的。
@nl101531 是的 大一点没有问题，但也只能稍微改善一点点，当流量大了后还是回到 要等待队列满还是小队列 快速拒绝的选择。 @lidlesseye11 是的，这可能是更简单健壮的算法：按队列增长比例增长核心数到最大数。 @mawerss1 直接拒绝执行就是设置小队列策略了。我现在就用这个设置。觉得还有点不够尽善尽美，没有用上队列的缓冲能力。一些小流量波动或网络波动或下游服务响应慢一点就会产生大量报警，这个时候并不需要加机器。 |
|
15
22yune OP @mawerss1 比如聚合接口最大响应时间 3 秒，正常响应时间 90%以上是 500ms 以下。假设最大线程数能到 1000 。那请求在队列中等待 2.5 秒是很可能会正常响应的。2.5 秒可以执行完成 5 个批次，队列可以缓存 5 * 1000 个请求，再大的队列就没用了。但初始核心线程可能是 100 。在队列满之后要等 25 才能消费完，这就是因线程增长太慢导致的。如果线程能随着队列排队增长而增长，则加入队列的都是可能正常响应的。在流量达到真正的负载上线时都不会失败。
|
 |
16
zeni123 2021-11-03 00:59:44 +08:00 via iPhone
当有多个机器的时候 线程池的设置可以有多套 profile
profile 1 20-40 profile 2 1000-2000 profile 3 100-100 ….. 就类似于 cpu 大小核心那样 |
|
17
zeni123 2021-11-03 01:22:19 +08:00
线程池的参数要根据具体任务类型而配置
当有多个机器的时候 线程池的设置可以有多套 profile 例如你有 50 台一样的机器 a 台设置成 Core 10 MAX 100 b 台设置成 Core 10 MAX 20 c 台设置成 Core 10 MAX 10 d 台设置成 Core 200 MAX 400 e 台设置成 Core 200 MAX 200 然后 a+b+c+d + e=50 随机给任务 ，统计任务的 throughput/响应 然后动态调节 a,b,c,d,e 的值使得 50 台机器总的 throughput/响应 最优 |
Select Language