我有一个联网Linux应用程序,它接收来自多个目的地的RTP流,进行非常简单的数据包修改,然后将流转发到最终目的地.
如何确定处理数据所需的线程数?我想,我无法为每个RTP流打开一个线程,因为可能有数千个.我应该考虑CPU核心的数量吗?还有什么重要的?谢谢.
了解在服务器上使用多个线程的目的很重要; 服务器中的许多线程用于减少延迟而不是提高速度.通过拥有更多线程,您不会使cpu更快,但是您更有可能在给定时间段内始终出现一个线程来处理请求.
拥有一堆只是并行移动数据的线程是一个相当低效的射击枪(每个请求创建一个线程自然就完全失败了).使用线程池模式可以是一种更有效,更集中的方法来减少延迟.
现在,在线程池中,您希望拥有至少与CPU /核心一样多的线程.你可以拥有更多,但额外的线程将再次只减少延迟而不是提高速度.
将组织服务器线程的问题视为类似于在超市中组织线路的问题.您想让很多收银员工作得更慢,还是一位收银员工作超快?快速收银员的问题不是速度,而是一个拥有大量杂货的顾客可能仍然占用他们的大部分时间.对许多线程的需求来自于一些请求会占用大量时间并阻塞所有线程的可能性.通过这种推理,您是否从许多较慢的收银员中受益取决于您是否拥有相同数量的杂货或数量差异很大.回到基本模型,这意味着您必须使用您的线程编号来确定在给定流量的特定特征时最佳情况,并查看处理每个请求所花费的时间.
通常,合理线程的数量取决于执行单元的数量,IO与计算的比率和可用内存.
XU
)这会计算同时有多少个线程处于活动状态.根据您的计算可能会或可能不会计算超线程等内容 - 混合指令工作负载更好.
%IO
)如果线程永远不会等待IO但总是计算(%IO = 0),则使用比XU更多的线程只会增加内存压力和上下文切换的开销.如果线程总是等待IO并且从不计算(%IO = 1),那么使用变体poll()
或者select()
可能是个好主意.
对于所有其他情况,XU / %IO
给出了完全使用可用GPU所需的线程数的近似值.
Mem
)这更像是一个上限.每个线程使用一定量的系统资源(MemUse
). Mem / MemUse
为您提供系统可支持的线程数的近似值.
即使您可以猜测或(更好地)测量上面的数字,整个系统的性能仍然可能受到其他因素的限制.例如,可能在系统上运行另一个服务,该服务使用一些XU和内存.另一个问题是一般可用的IO带宽(IOCap
).如果每个传输的字节所需的计算资源少于您提供的XU,那么显然您需要更少关注完全使用它们以及更多关于增加IO吞吐量的信息.
有关后一个问题的更多信息,请参阅此Google Talk有关Roofline模型的信息.