Question

我在R snowfall包中使用sfApply进行并行计算。有32000个测试要运行。启动计算时代码工作正常，它将创建46个Rscript.exe进程，每个Rscript.exe具有2％的CPU使用率。整体CPU使用率约为100％，结果不断写入磁盘。计算通常需要数十小时。奇怪的是Rscript.exe进程逐个变为逐渐变为非活动状态（cpu usage = 0），并且相应的cpu也处于非活动状态。两天后，通过查看cpu使用情况，只有一半的Rscript.exe处于活动状态，整体CPU使用率降低到50％。然而，这项工作还很遥远。随着时间的推移，越来越多的Rscript.exe变得不活跃，这使得工作持续很长时间。我想知道是什么让进程和CPU核心变为非活动状态？

我的电脑有46个逻辑核心。我在64位窗口7中使用Rstudio的R-3.4.0。以下'test'变量是32000 * 2矩阵。 myfunction正在解决几个微分方程。

感谢。

>=

Answer 1

由于snowfall::sfApply()在内部使用snow::parApply()，将您的数据（test）整理成（此处）46个块并将每个块发送到46名R工人中的一名。当一个工人完成它的块时，它就没有更多的工作了，而它只是闲置而剩下的块被其他工人处理。

您要做的是将数据拆分为较小的块，这将导致每个工作者平均处理多个块。我不知道（想想？）是否有可能降雪。并行包是R本身的一部分，它取代了雪包（降雪所依赖的），提供parApply()和parApplyLB()，后者将你的块分成最小尺寸，即每个数据一个元素（test）。有关详细信息，请参阅help("parApply", package = "parallel")。

future包（我是作者），为您提供了扩展数据分割量的选项。它不提供apply()版本，但您可以使用lapply()版本（以及parApply()如何在内部工作）。例如，每个工作者使用一个块的示例是：

library("future")
plan(multisession, workers = 46L)

## Coerce matrix into list with one element per matrix row
test_rows <- lapply(seq_len(nrow(test)), FUN = function(row) test[row,])

res <- future_lapply(test_rows, FUN = function(x) { 
  myfunction(x[1],x[2])
})

默认为

res <- future_lapply(test_rows, FUN = function(x) { 
  myfunction(x[1],x[2])
}, future.scheduling = 1.0)

如果要分割数据以便每个工作人员当时处理一行（参见parallel::parApplyLB()），则执行以下操作：

res <- future_lapply(test_rows, FUN = function(x) { 
  myfunction(x[1],x[2])
}, future.scheduling = Inf)

通过在[1，Inf]中设置future.scheduling，您可以控制平均块大小的大小。例如，在future.scheduling = 2.0返回之前，future_lapply()将使每个工作进程平均有两个数据块。

R降雪并行，Rscript.exe随着时间逐个变为无效

1 个答案: