合理估算线程池大小
来源:互联网 发布:淘宝智能版店铺 编辑:程序博客网 时间:2024/05/19 16:36
服务器性能IO优化 中发现一个估算公式:
最佳线程数目 = ((线程等待时间+线程CPU时间)/线程CPU时间 )* CPU数目
比如平均每个线程CPU运行时间为0.5s,而线程等待时间(非CPU运行时间,比如IO)为1.5s,CPU核心数为8,那么根据上面这个公式估算得到:((0.5+1.5)/0.5)*8=32。这个公式进一步转化为:
最佳线程数目 = (线程等待时间与线程CPU时间之比 + 1)* CPU数目
可以得出一个结论:
线程等待时间所占比例越高,需要越多线程。线程CPU时间所占比例越高,需要越少线程。
一个系统最快的部分是CPU,所以决定一个系统吞吐量上限的是CPU。增强CPU处理能力,可以提高系统吞吐量上限。但根据短板效应,真实的系统吞吐量并不能单纯根据CPU来计算。那要提高系统吞吐量,就需要从“系统短板”(比如网络延迟、IO)着手:
* 尽量提高短板操作的并行化比率,比如多线程下载技术
* 增强短板能力,比如用NIO替代IO
第一条可以联系到Amdahl定律,这条定律定义了串行系统并行化后的加速比计算公式:
加速比=优化前系统耗时 / 优化后系统耗时
加速比越大,表明系统并行化的优化效果越好。Addahl定律还给出了系统并行度、CPU数目和加速比的关系,加速比为Speedup,系统串行化比率(指串行执行代码所占比率)为F,CPU数目为N:
Speedup <= 1 / (F + (1-F)/N)
当N足够大时,串行化比率F越小,加速比Speedup越大。
是否使用线程池就一定比使用单线程高效呢?
答案是否定的,比如Redis就是单线程的,但它却非常高效,基本操作都能达到十万量级/s。从线程这个角度来看,部分原因在于:
* 多线程带来线程上下文切换开销,单线程就没有这种开销
* 锁
“Redis很快”更本质的原因在于:Redis基本都是内存操作,这种情况下单线程可以很高效地利用CPU。而多线程适用场景一般是:存在相当比例的IO和网络操作。
需要结合系统真实情况(比如是IO密集型或者是CPU密集型或者是纯内存操作)和硬件环境(CPU、内存、硬盘读写速度、网络状况等)来不断尝试以寻求一个符合实际的合理值。
参考:http://ifeve.com/how-to-calculate-threadpool-size/
- 合理估算线程池大小
- 如何合理的估算线程池大小
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小
- 如何合理地估算线程池大小
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小
- 如何合理地估算线程池大小
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小?
- 如何合理地估算线程池大小?
- 合理的估算线程池的大小
- 如何合理地估算线程池大小?
- 被自动装箱玩坏了,求大神指导
- 一些安全相关的HTTP响应头
- maven的安装
- 大数据量高并发的数据库优化 - [技术研究]
- STL常用函数简记(不断更新)
- 合理估算线程池大小
- CSV文件简介
- iOS7中读取通讯录信息授权问题
- sqlite 网络版发布
- shell中按列值统计行数及去除重复值
- 百度Frontia应用数据存储在后台运行不起来
- Nim游戏博弈
- linux字符串转换函数 simple_strtoul
- java中出现java.lang.NoSuchMethodError: main,Exception in thread "main"