2017-08-05 1 views
0

J'ai écrit un réseau seq2seq, en utilisant les vecteurs facebook fastText pour mes plongées. Je suis confronté à un problème où le modèle fonctionnera très bien peut-être 40% du temps, puis se bloque au début de la formation dans les 60% du temps. Certaines choses que j'ai considérées comme un réglage de mes paramètres peuvent causer un goulot d'étranglement, à cause de la taille des emebeddings, 300x100000 et une longueur de séquence de 10 unités en moyenne. Cela dit, en utilisant nvidia-smi, je peux voir que ce n'est pas un goulot de bouteille de calcul que le GPU montre seulement quelque part entre 9-20% d'utilisation à un moment donné. De même, le réseau effectue un certain redimensionnement des pools, mais je n'ai jamais frappé un MOO sur les pistes où mon modèle s'entraîne avec succès. J'utilise un assistant de train programmé pour mon décodeur d'entraînement et un décodeur de recherche de faisceau pour mon décodeur de prédiction. Cela commence à devenir un peu un crapshoot parce que chaque fois que je recommence l'entraînement après avoir fait un tweak, je risque de passer plus de temps à tuer le processus et à recommencer, puis à voir l'expérience se jouer. Im sur une instance p2xlarge EC2 avec un seul K80 à 12gib vram.Tensorflow se bloque. Quelles sont les choses que je peux faire pour déboguer le problème

De plus, y a-t-il un moyen de vérifier rapidement que l'accrochage est bien un blocage et que le tensorflow n'est pas vraiment dur pour le travail? J'ai la configuration de crochets pour imprimer à intervalles de 2000 pas pour le moment, mais il ne semble pas que même un pas ait été fait. Y at-il quelque chose qui me montrerait plus granuleusement qu'un certain opnode est en cours d'exécution. J'ai aussi essayé tfdbg Je ne pense pas qu'il soit compatible avec le contrib.estimator.estimator que j'utilise parce qu'il plante sur le invoke_stepper après quelques étapes à des erreurs bizarres qui proviennent de la trace de la pile. t semblent être liés à mon code.

+0

L'un des problèmes «suspendus» les plus courants concerne les files d'attente affamées. Est-ce que vous alimentez des données dans une file d'attente? Si tel est le cas, lancez un autre thread et imprimez la taille de cette file chaque seconde et voyez si vous démarrez la file d'attente. –

+2

Vous pouvez joindre avec gdb ou strace pour voir où il est suspendu. Si elle est suspendue à l'intérieur de l'appel session.run, vous pouvez ajouter des instructions tf.Print pour savoir sur quelle op elle est suspendue. –

Répondre

0

Dans ce cas particulier, après avoir attaché gdb et regardé les fils, il semblait que les choses se bloquaient. J'ai cherché un problème sur github de tensorflow lié à cela et il se trouve qu'il y avait un fil énorme sur un problème de livelocking potentiel qui ressemblait à la mienne. À la fin de ce fil, un autre problème connexe était lié au fait que les rédacteurs de résumé ne parvenaient pas à fermer les threads et à engendrer un nombre de threads impossible à gérer. J'utilisais un mécanisme de journalisation de niveau supérieur de tf.train "tf.train.LoggingTensorHook" et comme il s'avère que cela n'utilise pas les rédacteurs de résumé, le saut que j'ai fait était cette fonction pour une raison quelconque n'était pas jouer sympa avec le filetage interne de tensorflow et tout enfermer de la même manière. Depuis la suppression du hook de journalisation, j'ai eu 0 se bloque et a couru plus de 20 courses pour terminer avec succès ainsi que quelques courses plus longues avec plus de 100000 étapes.