我们有几个对延迟敏感的"管道"风格的程序，当在一个Linux内核上运行时，与在另一个内核上运行相比，它们的性能会显著下降。特别是，我们发现2.6.9 CentOS 4.x（RHEL4）内核的性能更好，而来自CentOS 5.x（RHL5）的2.6.18内核的性能更差。
所谓"管道"程序，我指的是一个有多个线程的程序。多个线程处理共享数据。在每个线程之间，都有一个队列。因此，线程A获取数据，推入Qab，线程B从Qab中提取，进行一些处理，然后推入Qbc，线程C从Qbc中提取，等等。初始数据来自网络（由第三方生成）。
我们基本上测量从接收数据到最后一个线程执行任务的时间。在我们的应用程序中，当从CentOS 4移动到CentOS 5时，我们看到从20微秒到50微秒的任何时间都会增加。
我已经使用了几种方法来分析我们的应用程序，并确定Centos5上增加的延迟来自队列操作（特别是弹出）。
然而，我可以通过使用taskset将程序绑定到可用内核的子集，来提高在centos5上的性能（与centos4相同）。
因此，在我看来，在centos4和5之间，发生了一些变化（可能是内核的变化），导致线程的调度方式不同（这种差异对我们的应用程序来说是次优的）。
虽然我可以用taskset（或通过sched_setAfinity（）在代码中）"解决"这个问题，但我的偏好是不必这样做。我希望有某种内核可调（或者可能是可调的集合），其默认值在不同版本之间发生了更改。
有人有这方面的经验吗？也许还有更多的领域需要调查？
更新：在这种特殊情况下，服务器供应商（Dell）的BIOS更新解决了该问题。我在这件衣服上拔了好一会儿头发。直到我回到基础，检查了我的供应商的BIOS更新。令人怀疑的是，其中一个更新说"在最高性能模式下提高性能"。一旦我升级了BIOS，CentOS 5就更快了——一般来说，尤其是在我的队列测试和实际生产运行中。
嗯。。如果从生产者-消费者队列执行pop（）操作所花费的时间对应用程序的整体性能产生了重大影响，我建议您的线程/workFlow的结构在某些地方不是最佳的。除非队列上存在大量争用，否则如果任何现代操作系统上的任何P-C队列推送/弹出都需要超过1µS左右的时间，即使队列使用经典的"计算机科学117-如何用三个信号量创建有界P-C队列"中的内核锁，我也会感到惊讶。
你能不能把做最少工作的线程的功能吸收到做最多工作的线程中，从而减少流经系统的每个整体工作项的推送/弹出次数？
多年来，Linux调度程序一直是一个激烈变化和争论的领域。您可能想要尝试一个非常新的内核并尝试一下。是的，你可能必须自己编译它——这对你有好处。您可能还想（当您拥有较新的内核时）考虑将不同的进程放在不同的容器中，将其他所有进程放在一个附加容器中，看看这是否有帮助。
至于其他随机的尝试，您可以提高各种进程的优先级，添加实时语义（注意，具有实时权限的有缺陷程序可能会耗尽系统的其余部分）。