Linux多线程系统上的线程调度差异?

前端之家收集整理的这篇文章主要介绍了Linux多线程系统上的线程调度差异?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我们有几个对延迟敏感的“管道”式程序,当在一个Linux内核上运行时,它们具有可测量的性能降级.特别是,我们看到2.6.9 CentOS 4.x(RHEL4)内核的性能更好,而CentOS 5.x(RHEL5)的2.6.18内核性能更差.

通过“管道”程序,我的意思是具有多个线程的程序.多线程处理共享数据.在每个线程之间,有一个队列.所以线程A获取数据,推入Qab,线程B从Qab拉出,做一些处理,然后推入Qbc,线程C从Qbc拉出等.初始数据来自网络(由第三方生成).

我们基本上测量从接收数据到最后一个线程执行任务的时间.在我们的应用程序中,当从CentOS 4移动到CentOS 5时,我们看到增加了20到50微秒.

我使用了一些分析我们的应用程序的方法,并确定CentOS 5上增加的延迟来自队列操作(特别是弹出).

但是,我可以通过使用taskset将程序绑定到可用内核的子集来提高CentOS 5的性能(与CentOS 4相同).

所以在我看来,在CentOS 4和5之间,有一些变化(可能是内核)导致线程的调度方式不同(这种差异对于我们的应用来说并不是最理想的).

虽然我可以使用taskset(或通过sched_setaffinity()代码)解决这个问题,但我的首选是不必这样做.我希望有一些内核可调参数(或者可能的可调参数集合),其默认值在不同版本之间进行了更改.

有人对此有经验吗?或许还有一些需要调查的领域?

更新:在此特定情况下,问题已通过服务器供应商(Dell)的BIOS更新解决.我把头发拉了一下这个.直到我回到基础,并检查我的供应商的BIOS更新.可疑的是,其中一个更新表示“在最高性能模式下提高性能”.一旦我升级了BIOS,CentOS 5就更快了 – 一般来说,但特别是在我的队列测试和实际生产运行中.

最佳答案
嗯..如果从生产者 – 消费者队列中进行pop()操作所花费的时间对应用程序的整体性能产生显着影响,我建议你的thread / workFlow的结构在某个地方不是最佳的.除非队列中存在大量争用,否则如果任何现代操作系统上的任何PC队列推送/弹出都需要超过μS左右,我会感到惊讶,即使队列在经典的“计算机科学”中使用内核锁定117 – 如何使用三种信号量方式创建一个有界的PC队列.

您是否可以将最少工作的线程的功能吸收到那些做得最多的线程中,从而减少流经系统的每个整体工作项的推/弹数量

猜你在找的Linux相关文章