关于线程池设置大小的考虑
考虑因素
-
cpu线程数
-
任务类型
-
CPU利用率
-
网络io 性能, 磁盘io性能
-
任务类型有两种
- cpu密集型
- 任务耗时低, 计算速度快, cpu等待空闲时间小。 所以设置的线程数不能太大, 以免出现抢占资源的情况和CPU时间片的切换带来的性能损耗, 一般为 N+1 。 (N 为CPU核数)。 我们Java程序中的线程池, 一般情况下是cpu密集型
- io密集型
- 最要消耗在io, CPU等待空闲时间大。所以设置的线程数可以考虑大一些, 一般设置为 2 * N 。 (N 为CPU核数)
- cpu密集型
数据库连接数计算公式
下面公式由 PostgreSQL 提供,不过底层原理是不变的,它适用于市面上绝大部分数据库产品。还有,你应该模拟预期的访问量,并通过下面的公式先设置一个偏合理的值,然后在实际的测试中,通过微调,来寻找最合适的连接数大小。
连接数 = ((核心数 * 2) + 有效磁盘数)
核心数不应包含超线程(hyper thread),即使打开了超线程也是如此,如果热点数据全被缓存了,那么有效磁盘数实际是0,随着缓存命中率的下降,有效磁盘数也逐渐趋近于实际的磁盘数。另外需要注意,这一公式作用于SSD 的效果如何,尚未明了。
好了,按照这个公式,如果说你的服务器 CPU 是 4核 i7 的,连接池大小应该为 ((4*2)+1)=9
。
取个整, 我们就设置为 10 吧。你这个行不行啊?10 也太小了吧!
你要是觉得不太行的话,可以跑个性能测试看看,我们可以保证,它能轻松支撑 3000 用户以 6000 TPS 的速率并发执行简单查询的场景。你还可以将连接池大小超过 10,那时,你会看到响应时长开始增加,TPS 开始下降
- 你应该经常会看到一些用户量不是很大的 web 应用中,为应付大约十来个的并发,却将数据库连接池设置成 100, 200 的情况。请不要过度配置您的数据库连接池的大小。
- 具体的线程池设置多少, 要结合理论和压力测试工具, 在微调, 取出最优结果