mclapply gibt NULL zufällig zurück

Question

Wenn ich mclapply verwende, gibt es von Zeit zu Zeit (wirklich zufällig) falsche Ergebnisse. Das Problem wird in anderen Posts im Internet, z. (http://r.789695.n4.nabble.com/Bug-in-mclapply-td4652743.html). Es wird jedoch keine Lösung bereitgestellt. Kann jemand dieses Problem beheben? Vielen Dank!

Answer 1

Das von Winston Chang gemeldete Problem, das Sie anführen, scheint in R 2.15.3 behoben worden zu sein. Es gab einen Fehler in mccollect das auftrat, wenn die Arbeiter Ergebnisse der Ergebnisliste zuweisen:

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

Dies schlägt fehl, wenn unserialize(r) eine NULL zurück, da auf diese Weise eine NULL zu einer Liste zuweisen löscht das entsprechende Element der Liste . Dies wurde in R 2.15.3 geändert:

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

, die eine sichere Art und Weise ist ein unbekannter Wert auf eine Liste zuzuordnen.

Wenn Sie also R < = 2.15.2 verwenden, besteht die Lösung darin, auf R> = 2.15.3 zu aktualisieren. Wenn Sie ein Problem mit R> = 2.15.3 haben, dann ist es vermutlich ein anderes Problem als das von Winston Chang.

---

Ich lese auch über die Probleme im R-Hilfe-Thread von Elizabeth Purdom diskutiert diskutiert. Ohne einen bestimmten Testfall, ist meine Vermutung, dass das Problem nicht aufgrund eines Fehlers in mclapply ist, weil ich die gleichen Symptome, die mit der folgenden Funktion wiedergeben kann:

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

Wenn ein Arbeiter von mclapply stirbt gestartet, während der Ausführung eine Aufgabe, aus irgendeinem Grunde (ein Signal empfangen wird, seg Verwerfungen, austritt), kehrt mclapply eine NULL für alle Aufgaben, die diese Arbeiter zugewiesen wurden:

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

[[2]] 
[1] 2 

[[3]] 
NULL 

[[4]] 
[1] 4 

In diesem Fall wurden NULL ist für Aufgaben ergeben 1 und 3 aufgrund von Vorplanung, obwohl nur Aufgabe 3 tatsächlich fehlgeschlagen ist.

Wenn ein Arbeiter stirbt, wenn eine Funktion wie parLapply oder clusterApply verwenden, wird ein Fehler gemeldet:

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

ich viele solcher Berichte gesehen habe, und ich denke, dass sie in großen Programmen passieren neigen, die verwenden viele Pakete, die sich nur schwer in reproduzierbare Testfälle verwandeln lassen.

Natürlich erhalten Sie in diesem Beispiel auch einen Fehler bei der Verwendung von lapply, obwohl der Fehler nicht wie bei mclapply ausgeblendet wird. Wenn das Problem bei der Verwendung von "lapply" nicht auftritt, liegt das möglicherweise daran, dass das Problem selten auftritt. Dies tritt nur bei sehr großen Läufen auf, die mit mclapply parallel ausgeführt werden. Es ist aber auch möglich, dass der Fehler auftritt, nicht weil die Tasks parallel ausgeführt werden, sondern weil sie von gegabelten Prozessen ausgeführt werden. Zum Beispiel werden verschiedene Grafikoperationen fehlschlagen, wenn sie in einem gegabelten Prozess ausgeführt werden.

Answer 2

Ich füge diese Antwort hinzu, damit andere, die diese Frage schlagen, nicht durch den langen Faden von Kommentaren waten müssen (ich bin der Kopfgeldjäger, aber nicht das OP).

mclapply füllt zunächst die Liste, die mit NULL erstellt wird. Wenn der Worker Rückgabewerte verarbeitet, überschreiben diese Werte NULL. Wenn ein Prozess stirbt, ohne jemals einen Wert zurückzugeben, gibt mclapply einen NULL zurück.

Wenn der Speicher niedrig wird, die Linux aus Memory-Killer (OOM Killer)

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

wird lautlos zu töten Prozesse starten. Es wird nichts auf die Konsole gedruckt, damit Sie wissen, was es tut, obwohl die Oom-Killer-Aktivitäten im Systemprotokoll angezeigt werden. In dieser Situation scheint die Ausgabe von mclapply zufällig mit NULLS kontaminiert worden zu sein.