Tensorflow 訓練時執行越來越慢，重啟後又變好是什麼原因？

1樓：大海燕

我的方法是用bash指令碼每隔一分鐘重啟一次python現在模型跑起來了，提前開始過端午了，實習以來下班最早的一天，全靠這個指令碼

#!/bin/sh

for i in `seq -w 1300 30 12550`doecho $i

timeout 60 python my.py $isleep 2

done

echo ""

2樓：董鑫

最有可能的原因是：你在 run session 的時候，重複的定義了很多新的op。因為你每個 batch 都是乙個迴圈，所以這麼樣下來，你的計算圖每次都變大，每個batch 的耗時也就越長。

另外乙個比較可能的原因是，你的 I/O 太慢，有時候從機械硬碟（HHD）就會出現這個問題。

3樓：安波西

原因：每次迭代計算圖中增加了新的節點，導致圖內節點越來越多，走向奔潰。

如何判斷你執行的session裡是否有新增的節點：在session裡使用graph.finalize()鎖定圖，程式報錯則說明圖有新節點產生。

如何找到新增的節點：檢查session裡是否有tf的op操作，如果你一下子找不出，可以用乙個直觀的辦法，比較graph的pb檔案，在每次迭代前輸入tf.train.

write_graph(sess.graph_def, "路徑", 'graph.pb', as_text=True)，迭代3次，生成了3個pb檔案，比較每個檔案多出的部分，就知道是哪個操作增加節點了，然後在進行修改。

4樓：八月

說下我的情況。

我也是越跑越慢，然後看大家說是不是在迴圈裡面加了op，我粗略一看，沒加什麼節點啊。然後在迴圈前sess.graph.

finalize()，發現在tf.one_hot這邊報錯，把tf.one_hot刪了自己用numpy寫了乙個onehot以後就跑的飛起了。

5樓：Coldwings

嚴格說那真不算是leak……

tf的文件裡，其實很明白地說了你要喂資料都要先立個placeholder再來喂（經提醒，大把資料要用pipeline），而不要直接甩個list/ndarray之類的玩意進去，否則會每個喂進去的資料都會套成個tfvariable，量小還好，量大了跑崩了都有可能……

6樓：Caleb Ge

今天遇到同樣的問題。後來發現是因為在執行時的session裡定義了tf的op導致的。這樣每一次迭代都會在graph裡增加新的節點，導致memory leak，程式越來越慢，最後強行退出。

至於在執行時程式有沒有增加節點，可以在session裡定義graph.finalize()鎖定graph，如果跑的時候報錯就證明程式在動態新增節點導致的越來越慢。詳細解釋請看這裡

也可以去看我的專案原始碼

今天看斯坦福CS20SI，note2的最底下，發現這個問題被定義為'lazy loading':

7樓：

我也發現了這個問題，上面的同學說的原因可能是GPU memory leak，我用的是一種曲線救國的方法；

每隔1000個batch，當速度明顯變慢的時候，就reset graph,然後才重新build模型，再load之前儲存的引數

tf.reset_default_graph()self.build_model()；

哪位大牛有更好的解決方法，請不吝賜教!