如何控制由 mclapply 引起的潜在分叉炸弹，尝试了 ulimit 但没有用
how to control potential fork bomb caused by mclapply, tried ulimit but didn't work
我在我的 R 脚本中使用 mclapply 进行并行计算。它节省了整体内存使用量并且速度很快，所以我想将它保留在我的脚本中。但是，我注意到的一件事是，在 运行 脚本期间生成的子进程数超过了我使用 mc.cores 指定的内核数。具体来说，我 运行 在具有 128 个内核的服务器上设置我的脚本。当我 运行 我的脚本时，我将 mc.cores 设置为 18。在脚本 运行 期间，我使用 htop 检查了与我的脚本相关的进程。首先，我可以找到 18 个这样的进程：
enter image description here
3_GA_optimization.R 是我的脚本。这一切看起来都不错。但我也发现有超过 100 个进程 运行ning 同时具有相似的内存和 CPU 使用率。下面的屏幕截图显示了其中的一些：
enter image description here
问题在于虽然我只需要 18 个内核，但脚本实际上使用了服务器上的所有 128 个内核，这使得服务器非常慢。所以我的第一个问题是为什么会这样？与黑色的18个过程相比，这些绿色的过程有什么区别？
我的第二个问题是，在运行宁Rscript 3_GA_optimization.R之前，我尝试使用ulimit -Su 100来设置我可以使用的最大进程数的软限制。我根据在 运行 脚本之前使用的当前进程数以及在 运行 脚本时要使用的内核数选择了 100。但是，我收到一条错误消息：
mcfork() 出错：
无法分叉，可能原因：资源暂时不可用
所以似乎 mclapply 必须生成比 mc.cores 更多的进程才能使脚本 运行，这让我感到困惑。所以我的第二个问题是为什么 mclapply 会这样？有没有其他方法可以解决 mclapply 可以使用的内核总数？
OP 在 2021-05-17 的评论中跟进并确认问题是他们通过 mclapply() 调用的 ranger 包的函数进行并行化，而这些函数又使用所有可用的 CPU 核心。这种嵌套并行性导致 R 使用的 CPU 内核比机器上可用的内核多得多。
我在我的 R 脚本中使用 mclapply 进行并行计算。它节省了整体内存使用量并且速度很快，所以我想将它保留在我的脚本中。但是，我注意到的一件事是，在 运行 脚本期间生成的子进程数超过了我使用 mc.cores 指定的内核数。具体来说，我 运行 在具有 128 个内核的服务器上设置我的脚本。当我 运行 我的脚本时，我将 mc.cores 设置为 18。在脚本 运行 期间，我使用 htop 检查了与我的脚本相关的进程。首先，我可以找到 18 个这样的进程：
enter image description here
3_GA_optimization.R 是我的脚本。这一切看起来都不错。但我也发现有超过 100 个进程 运行ning 同时具有相似的内存和 CPU 使用率。下面的屏幕截图显示了其中的一些： enter image description here
问题在于虽然我只需要 18 个内核，但脚本实际上使用了服务器上的所有 128 个内核，这使得服务器非常慢。所以我的第一个问题是为什么会这样？与黑色的18个过程相比，这些绿色的过程有什么区别？
我的第二个问题是，在运行宁Rscript 3_GA_optimization.R之前，我尝试使用ulimit -Su 100来设置我可以使用的最大进程数的软限制。我根据在 运行 脚本之前使用的当前进程数以及在 运行 脚本时要使用的内核数选择了 100。但是，我收到一条错误消息：
mcfork() 出错： 无法分叉，可能原因：资源暂时不可用
所以似乎 mclapply 必须生成比 mc.cores 更多的进程才能使脚本 运行，这让我感到困惑。所以我的第二个问题是为什么 mclapply 会这样？有没有其他方法可以解决 mclapply 可以使用的内核总数？
OP 在 2021-05-17 的评论中跟进并确认问题是他们通过 mclapply() 调用的 ranger 包的函数进行并行化，而这些函数又使用所有可用的 CPU 核心。这种嵌套并行性导致 R 使用的 CPU 内核比机器上可用的内核多得多。