如何控制由 mclapply 引起的潜在分叉炸弹,尝试了 ulimit 但没有奏效

问题描述

我在 R 脚本中使用 mclapply 进行并行计算。它节省了整体内存使用量并且速度很快,所以我想将它保留在我的脚本中。但是,我注意到的一件事是,在运行脚本期间生成的子进程数量超过了我使用 mc.cores 指定的核心数量。具体来说,我在具有 128 个内核的服务器上运行我的脚本。当我运行我的脚本时,我将 mc.cores 设置为 18。在运行脚本的过程中,我使用 htop 检查了与我的脚本相关的进程。首先,我可以找到 18 个这样的进程: enter image description here

3_GA_optimization.R 是我的脚本。这一切看起来都不错。但我也发现有 100 多个进程同时运行,内存和 cpu 使用率相似。下面的屏幕截图显示了其中的一些: enter image description here

这样做的问题是,虽然我只需要 18 个内核,但脚本实际上使用了服务器上的所有 128 个内核,这使得服务器非常慢。所以我的第一个问题是为什么会发生这种情况?与黑色的 18 个过程相比,这些绿色的过程有什么区别?

我的第二个问题是我尝试使用 ulimit -Su 100 来设置在运行 Rscript 3_GA_optimization.R 之前我可以使用的最大进程数的软限制。我根据我在运行脚本之前使用的当前进程数以及运行脚本时我想使用的内核数选择了 100。但是,我收到一条错误消息:

mcfork() 中的错误: 无法分叉,可能原因:资源暂时不可用

因此似乎 mclapply 必须生成mc.cores 多得多的进程才能运行脚本,这让我感到困惑。所以我的第二个问题是为什么 mclapply 会这样?有没有其他方法可以确定 mclapply 可以使用的内核总数?

解决方法

OP 在 2021-05-17 的评论中进行了跟进,并确认问题在于它们通过 mclapply() 调用的 ranger 包函数进行并行化,而后者又使用所有可用的 CPU 内核进行并行化。这种嵌套的并行性会导致 R 使用比机器上可用的多得多的 CPU 内核。