2013-12-19 15 views
11

mclapplyを使用しているときに(実際にはランダムに)間違った結果が得られます。この問題は、インターネット上の他の投稿、たとえば(http://r.789695.n4.nabble.com/Bug-in-mclapply-td4652743.html)。ただし、解決策はありません。誰もがこの問題を解決する方法を知っていますか?ありがとうございました!mclapplyはランダムにNULLを返します

+2

forkされたプロセスの1つが返るのに時間がかかる場合、mclapplyはnullを返します。ある種の時間が経過した後にプロセスが終了するようなタイムアウトが発生していると思いますが、ソースコード内のどこでもそのプロセスを見つけることができません。 –

+0

ユーザーがこの問題を報告する別のリンク:http://r.789695.n4.nabble.com/Problem-with-mclapply-losing-output-data-td3395746.html –

+0

Kudzu、Steve Westonは、メモリ不足のキロmclapplyプロセスが終了している可能性がありますが、私の場合はnullの原因になっていました。 oom_killerがあなたのnullを引き起こしていることを確認できますか? –

答えて

5

あなたが引用したWinston Changによって報告された問題は、R 2.15.3で修正されているようです。

if (is.raw(r)) res[[which(pid == pids)]] <- unserialize(r) 

unserialize(r)は、このようにリストにNULLを代入するので、NULLを返す場合、これは失敗したが、リストの対応する要素を削除します。結果リストに労働者の結果を割り当てるときに発生したmccollectにはバグがありました。これは、R 2.15.3で、

if (is.raw(r)) # unserialize(r) might be null 
    res[which(pid == pids)] <- list(unserialize(r)) 

に変更されました。これは、リストに不明な値を割り当てるのに安全な方法です。

したがって、R < = 2.15.2を使用している場合、解決策はR> = 2.15.3にアップグレードすることです。 R> = 2.15.3を使用して問題が発生した場合、おそらくそれはWinston Changによって報告されたものとは異なる問題です。


また、Elizabeth Purdomによって開始されたRヘルプスレッドで説明した問題を読みました。実行中mclapplyによって開始された労働者が死亡した場合

work <- function(i, poison) { 
    if (i == poison) quit(save='no') 
    i 
} 

:特定のテストケースがなければ、私の推測では、私は次の関数と同じ症状を再現できるため、問題が原因mclapplyのバグにないであるということです何らかの理由でタスク(、断層ワンセグ、信号を受信出)は、mclapplyその労働者に割り当てられたタスクのすべてのためにNULLを返します。この場合

> library(parallel) 
> mclapply(1:4, work, 3, mc.cores=2) 
[[1]] 
NULL 

[[2]] 
[1] 2 

[[3]] 
NULL 

[[4]] 
[1] 4 

、NULLのは、タスク1のために戻されましたタスク3のみが実際に失敗したにもかかわらず、予定通りに実行されています。私は多くのそのような報告書を見てきました

> cl <- makePSOCKcluster(3) 
> parLapply(cl, 1:4, work, 3) 
Error in unserialize(node$con) : error reading from connection 

、と私は彼らが使用する大規模なプログラムで発生する傾向があると思う:

などparLapplyやclusterApplyとしての機能を使用する場合に労働者が死亡した場合

は、エラーが報告されます再現可能なテストケースに変えにくいパッケージがたくさんあります。

もちろん、この例では、lapplyを使用するとエラーが発生しますが、エラーはmclapplyの場合のように隠されません。 lapplyを使用しているときに問題が発生していないようであれば、問題がほとんど発生しない可能性があるため、mclapplyを使用して並列実行される非常に大きな実行でのみ発生します。しかし、タスクが並行して実行されるのではなく、forkされたプロセスによって実行されるため、エラーが発生する可能性もあります。たとえば、フォークされたプロセスで実行されると、さまざまなグラフィックス操作が失敗します。

+0

R 3.0.1で問題が発生しているので、それは別のものだと思います。また、nullを返し、リストの要素を削除する関数の問題ではありません。むしろ関数はlapplyで実行しているときにnull以外の値を返しますが、パラレルで実行すると結果のリストにはnullが含まれます。他の人が問題を再現できるように私は例を取り上げています。 –

+0

私はスクールクラスターでRを使用していますが、実際にはバージョン2.15.2を使用しています。私はそれが新しいバージョンで解決されるかどうかを調べるつもりです。ありがとうございました! – Kudzu

+0

これは役に立ちます。私が呼んでいる関数は、並列で実行するとアプリオリが失敗するべきではありませんが、16コアの並列実行が関数を動作させないポイントにリソースを制限しているのではないかと思います。私は明日、いくつかの時間を持って、例を掲示しようとします(残念なことに、大量のデータがある大規模な実行になります)。 –

1

私はこの質問を打つ他の人がコメントの長いスレッドを渡る必要はありません(私は賞金の授与者ですが、OPではありません)。

mclapplyは、最初に作成したリストにNULLを設定します。ワーカーが戻り値を処理するとき、これらの値はNULLを上書きします。プロセスが値を返さずに終了した場合、mclapplyはNULLを返します。

メモリが低くなると、メモリキラーのうちのLinux(OOMキラー)

https://lwn.net/Articles/317814/

黙っプロセスを殺す開始します。 oom killerアクティビティはシステムログに表示されますが、コンソールには何をしているのかを知らせるために何も表示されません。この状況では、mclapplyの出力はランダムにNULLSで汚染されているように見えます。

関連する問題