在某些机器上，clone()/fork()/进程创建速度很慢

Question

在我的某些机器上创建新进程非常慢，而在其他机器上则不然。

这些机器都很相似，一些慢速机器与一些快速机器在相同的硬件和内核（2.6.32-26，Ubuntu 10.04）上运行完全相同的工作负载。不涉及进程创建的任务在所有机器上的速度相同。

例如，该程序在受影响的计算机上执行速度慢了约 50 倍：

int main()
{
    int i;
    for (i=0;i<10000;i++)
    {
        int p = fork();
        if (!p) exit(0);
        waitpid(p);
    }
    return 0;
}

什么可能导致任务创建速度慢得多，以及我可以在计算机中查找哪些其他差异？

Edit1：在这些机器上运行 bash 脚本（因为它们产生大量子进程）也非常慢，并且慢速脚本上的 strace 显示了 clone() 内核调用的速度减慢。

Edit2：vmstat 在快机器和慢机器上没有显示任何显着差异。它们都有足够的 RAM 来满足其工作负载，并且不会进行交换。

Edit3：我在 dmesg 中没有看到任何可疑的东西

Edit4：我不确定为什么现在出现在 stackoverflow 上，我不是在问上面的示例程序（只是用它来演示问题） ），但是 Linux 管理/调优，但如果人们认为它属于这里，那就酷了。

Answer 1

我们的应用程序堆栈也遇到了同样的问题，注意到应用程序性能大幅下降，并且 strace 的克隆时间更长。在 18 个节点上使用您的测试程序，我在我们遇到克隆时间缓慢的 3 个节点上重现了您的结果。所有节点都以相同的方式配置，但硬件略有不同。我们检查了 BIOS、vmstat、vm.overcommit_memory 并更换了 RAM，但没有任何改善。然后，我们将驱动器移至更新的硬件，问题得到解决。

CentOS 5.9
2.6.18-348.1.1.el5 #1 SMP 1 月 22 日星期二 16:19:19 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

“坏”和“好”lspci：

$ diff ../bad_lspci_sort ../good_lspci_sort 
< Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
> Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

< Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09)
> Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09)

< ISA bridge: Intel Corporation C204 Chipset Family LPC Controller (rev 05)
> ISA bridge: Intel Corporation C202 Chipset Family LPC Controller (rev 05)

< PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
> PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)

< VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 04)
> VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a)

Answer 2

我可能会首先使用 strace 来查看正在运行哪些系统调用，以及缓慢的系统调用挂在哪里。
我也很好奇你在这里如何使用 waitpid() 。在我的系统上， waitpid 的签名是

pid_t waitpid(pid_t pid, int *status, int options);

它看起来像是您正在使用 wait()，但传入子进程的 pid 而不是 int “status”，它具有您想要测试的状态标志的 OR为了。我预计，如果 PID 最终被解释为状态掩码，这可能会导致一些奇怪的事情发生。

Answer 3

需要注意的差异是内核（参数、设备驱动程序、活动模块）和硬件（CPU 版本、CPU 数量、内存配置、外围设备）。

另外：机器在重新启动/重新启动后会改变行为吗？

编辑：

低性能可能与（虚拟）内存层次结构有关。这个层次结构非常复杂，这种复杂性可能会导致奇怪的效果。在从 TLB 到数据缓存再到主内存的过程中，可能会发生奇怪的冲突。这些可能是由不同机器的内核的内存布局略有不同引起的，或者是因为内存层次结构（硬件）实际上略有不同。

当然可能还有其他原因，奇怪的外设（生成中断），不同的工作负载（例如活动进程的数量），...

如果您能解决这个问题，请分享结果！谢谢。

Answer 4

您是否检查过 BIOS 配置，以防 CPU 缓存被禁用，或者电源配置混乱，或者某些系统过热，或者某些内存降频...

Answer 5

所有系统的 /sbin/sysctl vm.overcommit_memory 值是否相同？如果不是，那就可以解释这种差异。

允许过度使用将使 fork() 更快，但这意味着新分配的页面不会得到 RAM 或交换的支持。如果/当你触摸一个无支持的页面时，操作系统必须找到它的支持——如果找不到，进程就会被终止。如果子进程所做的只是 exec()（就像在 system() 调用中发生的那样），那么这不是问题，因为所有这些未支持的页面都会被丢弃；但是，这可能会给 fork() 的其他用户带来严重问题。