Linux 每个进程的资源限制 - 红帽的一个深奥秘

Question

我有自己的多线程 C 程序，它的速度随着 CPU 内核的数量而平滑地扩展。我可以用 1、2、3 等线程运行它并获得线性加速。在 a 上速度高达约 5.5 倍Ubuntu Linux 机器上的 6 核 CPU。

我有机会在具有 4 个四核 Xeon 处理器、运行 Red Hat Enterprise Linux 的高端 Sunfire x4450 上运行该程序。我急切地期待看到 16 个内核可以以多快的速度运行我的 16 个线程的程序.. 但它的运行速度与两个线程相同！

经过大量的拉扯和调试，我看到我的程序确实在创建所有线程，它们确实同时运行，但线程本身比它们应该的要慢。 2 个线程的运行速度大约是 1 的 1.7 倍，但 3、4、8、10、16 个线程的运行速度都仅为 1.9 倍！我可以看到所有线程都在运行（没有停止或休眠），它们只是很慢。

为了检查硬件是否有问题，我同时独立运行了我的程序的 16 个副本。他们都全速奔跑。确实有 16 个内核，它们确实可以全速运行，并且确实有足够的 RAM（实际上这台机器有 64GB，而我每个进程只使用 1GB）。

所以，我的问题是，是否有一些操作系统解释，也许是一些每个进程的资源限制，它会自动缩减线程调度以防止一个进程占用机器。

线索是：

1. 我的程序无法访问磁盘或网络。它的 CPU 有限。它的速度在 Ubuntu Linux中的单CPU盒 用于 1-6 个线程的 hexacore i7。 6 线程实际上是 6 倍的加速。
2. 我的程序运行速度从未超过 16 核 Sunfire 的 2 倍加速 至强盒，适用于任意数量的线程 从2-16。
3. 运行 16 个副本 我的程序单线程运行 完美，所有 16 个同时运行 全速。
4. 顶部显示 1600% 分配的 CPU。 /proc/cpuinfo 显示 所有 16 个内核都以 2.9GHz 运行 速度（非低频怠速 1.6GHz）
5. 有 48GB 的​​可用 RAM，没有交换。

发生了什么事？是否有一些进程 CPU 限制策略？如果是这样，我怎么测量它？ 还有什么可以解释这种行为？

感谢您提供解决此问题的想法，即 2010 年至强减速之谜！

Answer 1

我最初的猜测是共享内存瓶颈。从你所说的来看，你的性能在 2 个 CPU 之后几乎持平。您最初责怪 Redhat，但我很想知道如果您在同一硬件上安装 Ubuntu 会发生什么。当然，我假设您在两个测试中都运行 64 位 SMP 内核。

主板在使用 2 个 CPU 时可能不会达到峰值。您有另一台具有多个内核的机器，它提供了更好的性能。新机器是否开启了超线程？ （这个答案与旧机器相比如何？）。您不是偶然在虚拟化环境中运行的吗？

总体而言，您的证据表明某处存在一个非常缓慢的瓶颈。正如您所说，您不受 I/O 限制，因此留下了 CPU 和内存。要么硬件有问题，要么硬件有问题。通过改变另一个来测试一个，你会很快缩小你的可能性。

Answer 2

对 rlimit 进行一些研究 - 您运行的 shell/用户帐户很可能有一些 RH 默认或管理员设置的资源限制。

Answer 3

当您看到这种奇怪的缩放行为时，尤其是如果看到多线程而不是多进程的问题，首先要考虑的一件事是锁争用和其他同步原语的影响，这可能导致在不同处理器上运行的线程必须相互等待，从而可能会迫使多个内核将其缓存刷新到主内存。

这意味着内存架构开始发挥作用，当您在单个硅片上拥有 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