foreach avec la connexion de base de données se fige sans aucune erreur, pour toujours

library(doParallel) 
library(RMySQL) 

no_cores <- as.integer(system('getconf _NPROCESSORS_ONLN', intern = TRUE)) - 1 
cluster <- makeCluster(no_cores) 
registerDoParallel(cl) 

clusterEvalQ(
    cluster, 
    mysql <- RMySQL::dbConnect(...) 
    } 
) 

r <- foreach(i = 1:50, .verbose = TRUE) %dopar% { dbGetQuery(mysql, 'show tables;')} 

no variables are automatically exported

Il n'y a pas d'erreur, aucune plainte. Rien, ça gèle. Je peux démarrer et utiliser un cluster sans connexion à la base de données.foreach avec la connexion de base de données se fige sans aucune erreur, pour toujours

Pensées?

Source

2017-08-24 Brandon Bertelsen

Quand est-ce que ça bloque? Lorsque vous appelez clusterEvalQ ou la boucle foreach?

J'ai quelques suggestions:

Utilisez outfile="" lors de la création du cluster pour obtenir une sortie de débogage;
Chargez RMySQL lors de l'initialisation du cluster;
Retourne NULL à partir de clusterEvalQ pour éviter la sérialisation des objets de connexion;
Assurez-vous d'appeler registerDoParallel pour que les tâches ne soient pas exécutées localement.

Voici un test qui utilise ces suggestions:

library(doParallel) 
cl <- makePSOCKcluster(3, outfile="") 
registerDoParallel(cl) 

clusterEvalQ(cl, { 
    library(RMySQL) 
    mysql <- dbConnect(MySQL(), user='root', 
        password='notmypasswd', dbname='mysql') 
    NULL 
}) 

r <- 
    foreach(i=1:50, .verbose=TRUE) %dopar% { 
    dbGetQuery(mysql, 'show tables;') 
    }

Ce test fonctionne pour moi. Quand je lance, je vois des messages comme:

no variables are automatically exported 
numValues: 50, numResults: 0, stopped: TRUE 
got results for task 1 
numValues: 50, numResults: 1, stopped: TRUE 
returning status FALSE 
got results for task 2

Si vous ne voyez que:

no variables are automatically exported

puis il se bloque, alors les travailleurs sont suspendus sans doute essayer d'effectuer la requête en utilisant la connexion de base de données. Cela me semble être un problème MySQL, mais je ne suis pas un expert MySQL.

Source

2017-08-24 19:18:00

Merci Steve, c'est définitivement la dernière partie. Je ne reçois rien, il se bloque alors peut-être que c'est la connexion DB qui échoue. Je souhaite juste qu'il y ait eu une sortie. Je l'ai laissé pendant environ 20 minutes et il était toujours là coincé, pas de messages d'erreur ou quoi que ce soit. J'ai également négligé d'ajouter 'registerDoParallel' à mon exemple, mais c'est dans mon réel. Je vais essayer vos suggestions et vous dire si l'un d'eux a travaillé. Appréciez votre attention ici! –

Pourriez-vous développer un peu ce que vous entendez par "éviter la sérialisation des objets de connexion"? –

@BrandonBertelsen Dans mon exemple, si je n'incluais pas 'NULL' lors de l'appel de' clusterEvalQ', il tenterait de renvoyer une liste des objets de connexion créés par les travailleurs. Étant donné que les objets de connexions de base de données contiennent des connexions de socket, cela entraînerait une erreur de sérialisation. Je ne pense pas que cela causerait de vrais problèmes, mais c'est dérangeant. –

foreach avec la connexion de base de données se fige sans aucune erreur, pour toujours

Répondre

Questions connexes