我有自己的多线程C程序，可以根据CPU内核的数量平滑地扩展速度。我可以使用1,2,3等线程运行它并获得线性加速...高达约5.5倍的速度Ubuntu Linux机箱上的6核CPU。
我有机会在非常高端的Sunfire x4450上运行该程序，其中包含4个运行Red Hat Enterprise Linux的四核Xeon处理器。我热切期待看到16个内核以16个线程运行程序的速度有多快。 但它的运行速度与两个线程相同！
以后进行大量的拔毛和调试，我发现我的程序确实在创建所有线程，它们实际上是同时运行的，但线程本身比它们应该更慢。 2个线程的运行速度比1快1.7倍，但是3个，4个，8个，10个，16个线程的运行速度仅为1.9倍！我可以看到所有线程都在运行（没有停滞或睡眠），它们只是很慢。
为了检查硬件是否有问题，我同时独立地运行了我的程序的第六个副本。他们全速奔跑。真的有16个核心，它们确实全速运行，而且确实有足够的RAM（事实上这台机器有64GB，我每个进程只使用1GB）。
所以，我的问题是，是否有一些操作系统解释，也许是一些每进程资源限制，它会自动缩减线程调度，以防止一个进程占用机器。
线索是：
发生了什么事？是否有一些进程CPU限制策略？如果是这样我怎么测量呢？ 还有什么可以解释这种行为？
感谢您的解决方案，2010年伟大至强减速之谜！
答案 0 :(得分：2)
对rlimit做一些研究 - 你运行的shell / user acct很可能有一些RH-default或admin-set资源限制。
答案 1 :(得分：1)
我最初的猜测是共享内存瓶颈。根据你的说法，你的性能在2个CPU之后几乎是平坦的。你最初责备Redhat，但我很想知道如果你在同一硬件上安装Ubuntu会发生什么。当然，我假设您在两个测试中运行64位SMP内核。
主板在使用2个CPU时可能无法达到峰值。您有另一台具有多个内核的计算机，可提供更好的性能。你有新机器开启超线程吗？ （这个答案与旧机器相比如何？）。您是不是偶然在虚拟化环境中运行？
总的来说，你的证据表明某个地方存在一个非常缓慢的瓶颈。如你所说，你不是I / O绑定的，因此留下了CPU和内存。硬件有问题，或者硬件有问题。通过改变另一个来测试一个，你将迅速缩小你的可能性。
答案 2 :(得分：0)
当你看到这种奇怪的扩展行为时，尤其是如果多线程出现问题，而不是多个进程出现问题，那么开始考虑的一件事就是锁争用和其他同步原语的影响，这可能导致在不同处理器上运行的线程必须彼此等待，可能迫使多个内核将其缓存刷新到主内存。
这意味着内存架构开始发挥作用，当您在单个芯片上拥有6个内核时，与在4个独立处理器之间进行协调时相比，这将大大加快。具体来说，单CPU情况可能根本不需要点击主内存来进行锁定操作 - 一切都可能在L3缓存级别处理，允许CPU在数据被刷新到后台主内存时继续处理
虽然我预计OP在这段时间之后已经对问题失去了兴趣（或者甚至可能无法再访问硬件），但检查这一点的一种方法是查看扩展到4个线程是否会改善进程关联性设置为将其锁定到单个物理CPU。更好的方法是分析应用程序本身，看看它花费的时间。随着您更改架构并增加内核数量，更难以猜测瓶颈在哪里，所以您真的需要开始测量事物直接，如下例所示：http://postgresql.1045698.n5.nabble.com/Sun-Donated-a-Sun-Fire-T2000-to-the-PostgreSQL-community-td2057445.html