如何控制mclapply引起的潜在fork炸弹，尝试过ulimit但没有用

Question

我在 R 脚本中使用 mclapply 进行并行计算。它节省了总体内存使用量并且速度很快，因此我想将其保留在我的脚本中。然而，我注意到的一件事是，运行脚本期间生成的子进程数量超过了我使用

mc.cores

指定的核心数量。具体来说，我在具有 128 个核心的服务器上运行我的脚本。当我运行脚本时，我将

mc.cores

设置为 18。在脚本运行期间，我使用

htop

检查了与我的脚本相关的进程。首先，我可以找到18个这样的进程：

3_GA_optimization.R 是我的脚本。这一切看起来都不错。但我还发现有超过 100 个进程同时运行，内存和 CPU 使用率相似。下面的屏幕截图显示了其中的一些：

这样做的问题是，虽然我只需要 18 个核心，但该脚本实际上使用了服务器上的所有 128 个核心，这使得服务器非常慢。所以我的第一个问题是为什么会发生这种情况？而这些绿色的工艺和18个黑色的工艺相比有什么区别呢？

我的第二个问题是，我尝试使用

ulimit -Su 100

来设置在运行

Rscript 3_GA_optimization.R

之前可以使用的最大进程数的软限制。我根据运行脚本之前当前使用的进程数以及运行脚本时想要使用的核心数选择了 100。但是，我收到错误消息：

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

所以看来 mclapply 必须生成比

mc.cores

更多的进程才能运行脚本，这让我感到困惑。所以我的第二个问题是为什么 mclapply 会有这样的行为？还有其他方法可以固定 mclapply 可以使用的核心总数吗？

Answer 1

OP 在 2021 年 5 月 17 日的评论中跟进，并确认问题是通过

mclapply()

调用 ranger 包的函数进行并行化，而该函数又使用所有可用的 CPU 内核进行并行化。这种嵌套并行性导致 R 使用比机器上可用的 CPU 内核多得多的 CPU 内核。