线程数,射多少最合理?

·  阅读 3294

Web-Server 有个配置,工作线程数。

Service 一般也有个配置,工作线程数。

经验丰富的架构师,懂得如何配置这些参数,使得系统的性能达到最优:有些业务设置为 CPU 核数的 2 倍,有些业务设置为 CPU 核数的 8 倍,有些业务设置为 CPU 核数的 32 倍。

“线程数” 的设置依据,是本文要讨论的问题。

工作线程数是不是设置的越大越好?

答案显然是否定的:

  • 服务器 CPU 核数有限,能够同时并发的线程数有限,单核 CPU 设置 1000 个工作线程没有意义

  • 线程切换有开销,如果线程切换过于频繁,反而会使性能降低

调用 sleep() 函数的时候,线程是否一直占用 CPU?

不占用,休眠时会把 CPU 让出来,给其他需要 CPU 资源的线程使用。

不止 sleep,一些阻塞调用,例如网络编程中的:

  • 阻塞 accept(),等待客户端连接

  • 阻塞 recv(),等待下游回包

都会让出 CPU 资源。

单核 CPU,设置多线程有意义么?

单核 CPU,设置多线程能否提高并发性能?

即使是单核,使用多线程也是有意义的,大多数情况也能提高并发:

  • 多线程编码可以让代码更加清晰,例如:IO 线程收发包,Worker 线程进行任务处理,Timeout 线程进行超时检测

  • 如果有一个任务一直占用 CPU 资源在进行计算,此时增加线程并不能增加并发,例如以下代码会一直占用 CPU,并使得 CPU 占用率达到 100%:

     while(1){ i++; }

  • 通常来说,Worker 线程一般不会一直占用 CPU 进行计算,此时即使 CPU 是单核,增加 Worker 线程也能够提高并发,因为这个线程在休息的时候,其他的线程可以继续工作

常见服务线程模型有几种?

了解常见的服务线程模型,有助于理解服务并发的原理,一般来说互联网常见的服务线程模型有两种:

  • IO 线程与工作线程通过任务队列解耦

  • 纯异步

第一种,IO 线程与工作线程通过队列解耦类模型。


如上图,大部分 Web-Server 与服务框架都是使用这样的一种 “IO 线程与 Worker 线程通过队列解耦” 类线程模型:

  • 有少数几个 IO 线程监听上游发过来的请求,并进行收发包(生产者)

  • 有一个或者多个任务队列,作为 IO 线程与 Worker 线程异步解耦的数据传输通道(临界资源)

  • 有多个工作线程执行正真的任务(消费者)

这个线程模型应用很广,符合大部分场景,这个线程模型的特点是,工作线程内部是同步阻塞执行任务的,因此可以通过增加 Worker 线程数来增加并发能力,今天要讨论的重点是 “该模型 Worker 线程数设置为多少能达到最大的并发”。

第二种,纯异步线程模型。

没有阻塞,这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量,该模型的缺点是:

  • 如果使用单线程模式,难以利用多 CPU 多核的优势

  • 程序员更习惯写同步代码,callback 的方式对代码的可读性有冲击,对程序员的要求也更高

  • 框架更复杂,往往需要 server 端收发组件,server 端队列,client 端收发组件,client 端队列,上下文管理组件,有限状态机组件,超时管理组件的支持

however,这个模型不是今天讨论的重点。

第一类 “IO 线程与工作线程通过队列解耦” 类线程模型,工作线程的工作模式是怎么样的?

了解工作线程的工作模式,对量化分析线程数的设置非常有帮助:


上图是一个典型的工作线程的处理过程,从开始处理 start 到结束处理 end,该任务的处理共有 7 个步骤:

(1)从工作队列里拿出任务,进行一些本地初始化计算,例如 http 协议分析、参数解析、参数校验等;

(2)访问 cache 拿一些数据;

(3)拿到 cache 里的数据后,再进行一些本地计算,这些计算和业务逻辑相关;

(4)通过 RPC 调用下游 service 再拿一些数据,或者让下游 service 去处理一些相关的任务;

(5)RPC 调用结束后,再进行一些本地计算,怎么计算和业务逻辑相关;

(6)访问 DB 进行一些数据操作;

(7)操作完数据库之后做一些收尾工作,同样这些收尾工作也是本地计算,和业务逻辑相关;

分析整个处理的时间轴,会发现:

  • 其中 1,3,5,7 步骤中(上图中粉色时间轴),线程进行本地业务逻辑计算时需要占用 CPU

  • 而 2,4,6 步骤中(上图中橙色时间轴),访问 cache、service、DB 过程中线程处于一个等待结果的状态,不需要占用 CPU,进一步的分解,这个 “等待结果” 的时间共分为三部分:

    2.1)请求在网络上传输到下游的 cache、service、DB

    2.2)下游 cache、service、DB 进行任务处理

    2.3)cache、service、DB 将报文在网络上传回工作线程

如何量化分析,并合理设置工作线程数呢?

通过上面的分析,Worker 线程在执行的过程中:

  • 有一部计算时间需要占用 CPU

  • 另一部分等待时间不需要占用 CPU

通过量化分析,例如打日志进行统计,可以统计出整个 Worker 线程执行过程中这两部分时间的比例,例如:

  • 执行计算,占用 CPU 的时间(粉色时间轴)是 100ms

  • 等待时间,不占用 CPU 的时间(橙色时间轴)也是 100ms

得到的结果是,这个线程计算和等待的时间是 1:1,即有 50% 的时间在计算(占用 CPU),50% 的时间在等待(不占用 CPU):

  • 假设此时是单核,则设置为 2 个工作线程就可以把 CPU 充分利用起来,让 CPU 跑到 100%

  • 假设此时是 N 核,则设置为 2N 个工作现场就可以把 CPU 充分利用起来,让 CPU 跑到 N*100%

当当当当!!!

结论来了

N 核服务器,通过执行业务的单线程分析出本地计算时间为 x,等待时间为 y,则工作线程数(线程池线程数)设置为 N*(x+y)/x,能让 CPU 的利用率最大化。

一般来说,非 CPU 密集型的业务(加解密、压缩解压缩、搜索排序等业务是 CPU 密集型的业务),瓶颈都在后端数据库访问或者 RPC 调用,本地 CPU 计算的时间很少,所以设置几十或者几百个工作线程是能够提升吞吐量的。

GET 新技能了吗?

思考题

贵司线程数设置为多少?

画外音:随手设了一个 200?

分类:
后端
分类:
后端
收藏成功!
已添加到「」, 点击更改