r - parLapply循环中多个文件在R中的curl内存使用情况

Question

我有一个项目在 ec2 上多线程下载约 2000 万份 PDF。我最精通 R，而且它是一次性的，所以我最初的评估是 bash 脚本节省的时间不足以证明花在学习曲线上的时间是合理的。所以我决定只从 R 脚本中调用 curl。该实例是基于 ubuntu 的 c4.8xlarge rstudio 服务器，具有 36 个内核和 60 gigs 内存。

使用我尝试过的任何方法，它都会很快达到最大内存。它运行良好，但我担心交换内存会减慢速度。 curl_download 或 curl_fetch_disk 的工作速度比 native download.file 函数快得多(每 0.05 秒一个 pdf，而 0.2 秒)，但它们都非常快地运行到最大内存，然后似乎用空文件填充目录。使用 native 函数，我通过大量使用 try() 和 invisible() 来抑制输出来处理内存问题。这似乎对 curl 包没有帮助。

如果有人可以帮助我，我有三个相关的问题。

(1) 我对内存使用方式的理解是否正确，因为不必要的内存交换会导致脚本变慢？

(2) curl_fetch_disk 应该直接写入磁盘，有没有人知道为什么它会使用这么多内存？

(3) 在 R 中有什么好的方法可以做到这一点，还是我最好学习一些 bash 脚本？

当前使用 curl_download 的方法

getfile_sweep.fun <- function(url
                          ,filename){
  invisible(
    try(
      curl_download(url
                ,destfile=filename
                ,quiet=T
      )
    )
  )
}

使用 native download.file 的先前方法

getfile_sweep.fun <- function(url
                            ,filename){
  invisible(
    try(
      download.file(url
                  ,destfile=filename
                  ,quiet=T
                  ,method="curl"
                  )
    )
  )
}

parLapply 循环

len <- nrow(url_sweep.df)

gc.vec <- unlist(lapply(0:35, function(x) x + seq(
from=100,to=len,by=1000)))

gc.vec <- gc.vec[order(gc.vec)]

start.time <- Sys.time()

ptm <- proc.time()
cl <- makeCluster(detectCores()-1,type="FORK")
invisible(
  parLapply(cl,1:len, function(x){
    invisible(
      try(
        getfile_sweep.fun(
          url = url_sweep.df[x,"url"]
          ,filename = url_sweep.df[x,"filename"]
        )
      )
    )
    if(x %in% gc.vec){
      gc()
    }
  }
  )
)
stopCluster(cl)
Sweep.time <- proc.time() - ptm

数据样本 -

url_sweep.df 示例:
https://www.dropbox.com/s/anldby6tcxjwazc/url_sweep_sample.rds?dl=0

现有文件名示例:
https://www.dropbox.com/s/0n0phz4h5925qk6/existing_filenames_sample.rds?dl=0

Answer 1

笔记:

1-我没有这么强大的系统可用，所以我无法重现提到的每个问题。

2-所有评论都在这里总结

3- 据说机器收到了升级:EBS to provisioned SSD w/ 6000 IOPs/sec ，但是问题仍然存在

可能的问题:

A- 如果内存交换开始发生，那么您也不是纯粹使用 RAM。我想R将越来越难找到可用的连续内存空间。

B- 工作负载和完成工作负载所需的时间，与核心数量相比

c- parallel设置和fork cluster
可能的解决方案和故障排除:

B- 限制内存使用

C- 限制核心数量

D-如果代码在像个人桌面这样的小型机器上运行良好，那么问题在于如何设置并行使用，或者使用 fork 集群。

仍然要尝试的事情:

A- 通常在 parallel 中运行作业招致 overhead , 现在更多 cores你有，你会看到更多的效果。当你通过很多只需要很少时间的工作时(认为小于秒)，这将导致 overhead 的增加与不断插入工作有关。尝试限制core to 8就像您的桌面并尝试您的代码？代码运行正常吗？如果是，则尝试在增加程序可用的内核时增加工作量。

从内核数量和内存数量的低端开始，随着工作负载的增加而增加它们并查看下降发生的位置。

B- 我将发布一个关于 Parallelism in R 的摘要，这可能会帮助你捕获我们错过的东西

什么有效:
限制核心数量已经解决了这个问题。正如 OP 所提到的，他还对代码进行了其他更改，但是我无权访问它们。