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

Question

我mclapply在我的 R 脚本中使用并行计算。它节省了整体内存使用量并且速度很快，所以我想将它保存在我的脚本中。但是，我注意到的一件事是，在运行脚本期间生成的子进程数量超过了我使用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？

标签： rparallel-processingforkcoremclapply

Answer 1

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