2017-06-16 89 views
0

我在R降雪包中使用sfApply進行並行計算。有32000個測試運行。代碼在啓動計算時工作正常,它會創建46個Rscript.exe進程,每個Rscript.exe的CPU使用率爲2%。整體CPU使用率約爲100%,並且結果不斷寫入磁盤。計算通常需要幾十個小時。奇怪的是,Rscript.exe進程逐漸變爲非活動狀態(cpu usage = 0),並且相應的cpu也處於非活動狀態。兩天後,通過查看CPU使用情況,只有一半Rscript.exe處於活動狀態,整體CPU使用率降至50%。但是,這項工作還很遙遠。隨着時間的推移,越來越多的Rscript.exe變得無效,這使得工作持續很長時間。我想知道是什麼讓進程和cpu核心處於不活動狀態?R降雪並行,Rscript.exe隨着時間的推移逐漸失效

我的電腦有46個邏輯核心。我在64位Windows 7中使用了Rstudio的R-3.4.0。以下「測試」變量是32000 * 2矩陣。我的功能是解決一些微分方程。

謝謝。

library(snowfall) 
    sfInit(parallel=TRUE, cpus=46) 
    Sys.time() 
    sfLibrary(deSolve) 
    sfExport("myfunction","test") 
    res<-sfApply(test,1,function(x){myfunction(x[1],x[2])}) 
    sfStop() 
    Sys.time() 
+0

內存使用情況如何?有足夠的RAM可用嗎?這裏沒有太多要走,但你可以嘗試一次只運行幾項任務,看看它們是否通過。開始增加任務的數量,直到遇到瓶頸。 –

+0

謝謝。 RAM可用,僅使用10G(總共64G)。我可以嘗試,但問題是過程正在逐漸失去活性。任務正在繼續,只是越來越少cpus。這就像在計算過程中讓核心一個接一個睡着。 – yan

+0

對不起,我沒有想法。也許你可以使用其他並行工具,比如'parallel'或'foreach'? –

回答

0

什麼你所描述聽起來很合理,因爲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,天道酬勤]設置future.scheduling,你可以控制平均塊大小是多大。例如,在future_lapply()返回之前,future.scheduling = 2.0將使每個工作進程平均有兩個數據塊。

相關問題