パッケージのparApply関数を使用しようとしたときに表示される次のメッセージのトラブルシューティングを試みています。parallel
Error in unserialize(node$con) : error reading from connection
以下は私がやっていることのモックアップです：
c0<-makeCluster(16,outfile='');clusterEvalQ(c0,library(survival));
aa <- array(rexp(1e4),c(100,50,2));
bb<-parApply(c0,aa,1,function(ii) {
oo<-try(summary(coxph(Surv(c(ii))~gl(2,50)))$coef[1,]);
if(class(oo)[1]=='try-error') rep(NA,5) else oo
});
...エラーが発生しないことを除いて。私が parApply 内から呼び出す実際の関数は、私が自分で書いた巨大なもので、ここに投稿するには長すぎます。しかし、誰かに私の機能をデバッグしてもらうつもりはありません。私は、より詳細なデバッグ情報をどこで探すべきか、そしてtry()その目的を達成するために誰を/何を絞め殺さなければならないかを見つけようとしています.
この関数は、 standardapply()およびでは機能しますが、 では機能しませaaply(...,.parallel=FALSE)んaaply(...,parallel=TRUE)。
画面ログに表示される唯一のもの (使用するパッケージのロードに伴う通常の警告メッセージを除く) はExecution halted.
するとstopCluster(c0)、次の追加出力が得られます。
Error in serialize(data, node$con) : ignoring SIGPIPE signal
他にどこを見るべきか知っている人はいますか？CentOS リリース 5.4 (Final) で R 2.15.1 を実行しています。でキャッチしようとしても、上方に伝播するエラーの種類はありますtry()か? parallelワーカーノードをより忍耐強くするために設定できるタイムアウトオプションはありますか?
まず、makeCluster(16,outfile='',type='FORK')デフォルトのSOCKタイプのクラスターの代わりに使い始めました。FORK はすべての依存関係を手動でエクスポートすることを忘れずに環境全体を複製するため、および/または (ここでは不明) FORK はループバック ポートを介してトークン化されたデータを送信する必要がないため、これは非常に安定しました。
とにかく、状況によってerror reading from connectionは戻ってくるでしょう。なじみのない問題領域とあいまいなエラー メッセージに気を取られ、いつものようにここでも同じトラブルシューティング ヒューリスティックが適用されることを忘れていました。
- 同じデータが常に問題を引き起こしますか? 私にとっては、はい、それは常にデータセットの同じ領域で発生しました。
- 問題を再現するために必要なそのデータセットの最小機能は何ですか? 入力データを連続して細分化すると、問題の原因となった正確な列が明らかになりました。そのベクトルで目的関数を直接呼び出すと、今回は通常の R 環境で問題が発生しました。目的関数を 1 行ずつステップ実行すると、失敗した場所が明らかになりました。
回答者が暗示したように、try()エラーのみをキャッチすることが判明しました。間違ったデータ型、間違ったサイズ、または NULL である予期しない結果は、すぐに通過try()しtryCatch()、結果を配列に戻そうとするものは何でもクラッシュします!
神に感謝しますそれは、クレイジーな非決定論的な競合状態などではありませんでした。うーん。読んでくれてありがとう、私の経験が他の誰かに役立つことを願っています。