2017-08-05 12 views
0

私は埋め込みのためにfacebook fastTextベクトルを使ってseq2seqネットワークを作成しました。私は、モデルが実行され、時間の40%がうまく訓練され、残りの60%の訓練の開始時にランダムにハングするという問題にぶつかっています。Tensorflowがハングします。問題をデバッグするためにできることは何ですか

私の考えているパラメータのいくつかは、エフェメレーションの大きさが300x100000で、シーケンスの長さが平均10単位であるため、ボトルネックを引き起こす可能性があります。つまり、nvidia-smiを使用すると、GPUは特定の時間に9〜20%の使用率しか示さないため、計算上のボトルネックではないことがわかります。同様に、ネットワークはいくつかのプールのサイズ変更を行いますが、私のモデルが正常に実行されたランでOOMを打つことはありません。私は私のトレーニングデコーダ用のスケジュールされた電車ヘルパーと、私の予測デコーダ用のビームサーチデコーダを使用しています。

微調整をした後にトレーニングを再開するたびに、私はプロセスを強制終了して実際に実験を行うより多くの時間を費やしてしまう危険があるためです。 ImはEC2 p2xlargeインスタンスで、12gibのvramで1つのK80を使用します。

さらに、ハングアップが実際にハングしていること、テンソルフローが実際には私のために数字を処理するのは難しいことをすぐに確認する方法はありますか?私はフックセットアップを現時点で2000ステップの間隔で印刷するように設定していますが、一歩も踏み出されていないようです。特定のopnodeが実行されていることをより詳細に示すものがありますか?

私もtfdbgを試してみましたが、私が使用しているcontrib.estimator.estimatorと互換性がないと思われます。なぜなら、invoke_stepperでいくつかのステップを実行した後にクラッシュし、私のコードに関連しているようです。

+0

最も一般的な「懸垂」問題の1つは、飢えたキューです。データをキューに入れていますか?もしそうなら、別のスレッドを起動し、そのキューのサイズを毎秒印刷して、キューを開始しているかどうか確認してください。 –

+2

gdbやstraceを付けて、どこにぶら下がっているのかを確認できます。それがsession.runの呼び出しの中にぶら下がっている場合は、tf.Printステートメントを追加して、どのオペレーションが掛かっているのか把握することができます。 –

答えて

0

この特定のケースでは、gdbをアタッチしてスレッドを見ると、ロックされているように見えます。私はそれに関連したテンソルフローのgithubに関する問題を探しました。それは、私のような潜在的なライブロック問題に大きな糸があったことが判明しました。そのスレッドの終わりには、別の関連する問題が、スレッドをクローズして管理不能なスレッド数を生成しないサマリー・ライターとリンクしていました。

私は、tf.train "tf.train.LoggingTensorHook"の上位レベルのロギングメカニズムを使用していましたが、これはサマリーライターを使用していないことがわかりましたので、何らかの理由でこの関数が作成したものでしたテンソルフローの内部スレッディングを使ってうまくやっていて、同様の方法ですべてをロックしています。ロギングフックを削除して以来、私は0がハングアップし、20以上のランが成功し、さらに100000を超えるステップが実行されています。

関連する問題