【问题标题】:R system() process always uses same CPU, not multi-threaded/multi-coreR system() 进程始终使用相同的 CPU,而不是多线程/多核
【发布时间】:2013-12-02 09:07:29
【问题描述】:

在 Linux 3.12.0 上的 R 3.0.2 中,我使用 system() 函数来执行一些任务。如果我通过 Rsystem() 之外的 Rscript 在命令行上执行这些任务,所期望的效果是让每个任务都像它们一样运行。

但是,当通过system() 在 R 中执行它们时,每个任务都绑定到来自主 R 进程的同一个 CPU。

换句话说:

当通过 RScript 直接从 R 外部的 bash shell 启动时,每个任务都尽可能在自己的核心上运行(这是理想的)

当通过system() 在 R 中启动时,每个任务都在同一个内核上运行。没有多核共享。如果我有 100 个任务,它们都卡在一个核心上。

我不知道如何在 R 中生成一个进程,以便每个进程都使用自己的核心。

我正在使用一个简单的测试来消耗 CPU 周期,因此我可以使用 top/htop 测量效果:

dd if=/dev/urandom bs=32k count=1000 | bzip2 -9 >> /dev/null

当这个简单的测试在 R 之外多次启动时,每次迭代都有自己的核心。但是当我在 R 中启动它时:

system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)

它们都卡在一个内核上。

这是运行system() 的 4 次同时/并发迭代后的可视化。

请帮助我,我需要能够告诉 R 启动新任务,每个任务都在自己的核心中运行。

2013 年 12 月 4 日更新:

我尝试使用 Python 进行测试:

import thread
thread.start_new_thread(os.system,("/bin/dd if=/dev/urandom of=/dev/null bs=32k count=2000",))

我重复了几次新线程,一切正常(使用多个内核,每个线程一个)。

所以我认为在 R 中安装 rPython 包,并在 R 中尝试相同的操作:

python.exec("import thread")
python.exec("thread.start_new_thread(os.system,('/bin/dd if=/dev/urandom of=/dev/null bs=32k count=2000',))")

不幸的是,即使在重复调用之后,它也再次被限制为单个内核。为什么从 R 执行时,启动的所有内容都仅限于单核?

【问题讨论】:

  • 我认为不使用附加包或至少parallel 包是不可能的。你找到here更多解释。
  • 您是否在系统上尝试过GNU parallel?或者,如果您正在运行 4 个进程,您可以尝试在启动脚本中使用 xargsP - 4 '4 maxprocs' 选项来尝试强制并行执行??
  • @agstudy,我试过并行包。我什至无法让它正常工作,所以我不知道我的 R 3.0.2 x64 的 Debian 安装是否以某种方式被冲洗掉了,或者是什么。并行仍然仅限于单核。
  • @StephenHenderson,对不起,伙计,我看不出这两种方法在这种情况下是如何工作的。我使用 system() 生成的实际命令都是独一无二的。
  • 好的,如果它们是真正独特的,例如diff 命令它不起作用,但通常会运行运行相同命令的文件,例如压缩(您的示例)它们或类似命令,在这种情况下,您可以用文件名列表中的并行或 xargs -P 命令替换循环。也就是说,我从未尝试过它,我不知道它是否有效……虽然我已经从 bash shell 并行运行了多个 Rscript。

标签: multithreading r process multicore


【解决方案1】:

根据@agstudy 的评论,您应该先让parallel 工作。在我的系统上,这使用了多个内核:

f<-function(x)system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)
library(parallel)
mclapply(1:4,f,mc.cores=4)

我自己会在评论中写这个,但是太长了。我知道您说过您已经尝试过 parallel 软件包,但我想确认您正确使用了它。如果不起作用,您能否确认非系统调用正确使用mclapply,例如这个?

a<-mclapply(rep(1e8,4),rnorm,mc.cores=4)

阅读您的 cmets,我怀疑您的 pthreads Linux 软件包已过时且已损坏。在我的系统上,我使用的是 libpthread-2.15.so(不是 2.13)。如果您使用的是 Ubuntu,您可以通过 apt-get install libpthread-stubs0 获取最新的信息。

另外,请注意您应该使用parallel,而不是multicore。如果您在at the docs 中查找parallel,您会注意到他们已将multicore 上的工作纳入其中。


阅读您的下一组 cmets,我必须坚持认为,自 2.14 以来,R 中包含的是 parallel 而不是 multicore。您可以在CRAN Task View 上阅读有关此内容的信息。

parallel 工作至关重要。我之前告诉过你,你可以直接从源代码编译它,但这是不正确的。我想重新编译它的唯一方法是从源代码编译 R。

您是否还可以验证您的 CPU 关联设置是否正确?您还可以检查 R 是否可以检测内核数?运行:

library(parallel)
mcaffinity()
# Should be c(1,2,3,4) for you.
detectCores()
# Should be 4 for you.

【讨论】:

  • 您好,感谢您的尝试。第一个代码块产生四个进程,我可以在 htop 等上看到它们。但是像示例截图一样锁定到一个内核。您的第二个示例(非系统调用)也仅使用了 100% 的单核。既然我们已经获得了这些新信息,您能否告诉我为什么我的并行库无法正常工作?
  • 新信息...刚刚通过 CLI R 而不是 RStudio 尝试过,它给了我一个段错误。这是 pastebin:pastebin.com/1SWhH4Zd——此外,我检查了内核日志,发现:[586018.637080] rsession[28883]: segfault at 7f1e1eeda9d0 ip 00007f1e23912d8c sp 00007fff484ab730 error 4 in libpthread-2.13.0+1701] .我做了一个快速的谷歌,但没有看到其他人与 R 有这个问题。但它似乎是罪魁祸首,如果我只知道为什么。
  • 我刚刚删除了并行包,多核,foreach,doParallel,doSNOW。然后我重新安装了多核,我认为这是 R 3.0.2 应该使用的而不是并行的。它包括 mclapply。仍然没有喜悦,在 CLI 和单核上出现同样的段错误。我找不到其他遇到此问题的人,所以不知道下一步该去哪里。
  • @user1530260 我已经更新了我的答案,我怀疑你的pthreads 坏了。
  • 可能与 OpenBlas 有关。有可能称为 OpenBlas 的不同 R 会话本身将所有工作负载转移到单个内核。见grokbase.com/t/r/r-sig-hpc/124qe5gmwn/parallel-and-openblas
【解决方案2】:

我测试运行:

system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)
system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)
system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)
system("dd if=/dev/urandom bs=32k count=2000 | bzip2 -9 >> /dev/null", ignore.stdout=TRUE,ignore.stderr=TRUE,wait=FALSE)

在带有 R 3.0.2 的 Linux 2.6.32 和带有 R 2.15.2 的 Linux 3.8.0 上。在这两种情况下,它都会占用 4 个 CPU 内核(如您所料)。

-- 编辑--

我在 Virtual Box 机器上安装了 Linux 3.12,而这里的 R 3.0.2 也符合我的预期:占用 4 个 CPU。它甚至会在 CPU 之间缓慢徘徊 - 因此每个进程不会粘在同一个 CPU 上,而是每秒左右变化一次。

这让我相信你的系统是一些本地修改,迫使 R 只使用一个 CPU。

根据您的描述,我猜想本地修改是在 R 中而不是系统范围内(因为您的 Python 在生成更多进程时没有问题)。

修改可能仅针对您的用户,因此请创建一个新用户并尝试使用它。如果它适用于新用户,我们需要弄清楚您的用户 ID 安装了什么。

如果它不适用于新用户,则可能是全局安装的 R 库导致问题。安装较旧的 R 版本并尝试一下。如果旧版本有效,则您的 R 3.0.2 安装可能已损坏。删除它并重新安装。

【讨论】:

  • 在彻底清除之后,我已经完全重新安装了 R。它没有任何区别。我目前正在部署一个全新的物理服务器,看看是否能解决它。由于我这边时间有限,还需要几天时间。我无法想象在这个特定的配置中发生了什么“修改”导致它被绑定到单个 CPU。
  • 您能否确认您是否为 libpthread 等进行了任何特殊的 apt-get 安装,或者只是使用了 R 3.0.2 内置的库(并行)?你能告诉我一个名称为 pthread 的已安装包的列表吗,因为我的系统上似乎确实存在某种链接 - libpthread.so 的段错误 + 对一个核心的限制必须相关。
  • 我使用了 R 的 CRAN 版本。我没有对 pthreads 进行任何特殊安装,也没有使用库(并行)。我所做的只是:将 CRAN 添加到 sources.list; apt-get 安装 r-base-core; R(回车)粘贴 4 行。
  • 由于冬季风暴和 UPS 无法交付(可能要到周二才能交付),我还无法构建新的物理服务器。由于很明显问题出在我的配置上,不知何故,我将继续为此而努力(新系统、重新安装等)。感谢您帮助证明它有效,这很重要。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-03-24
  • 2017-03-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多