pytorch顯存越來越多的一個原因
|
1
2
3
4
|
optimizer.zero_grad()loss.backward()optimizer.step()train_loss += loss |
參考了別人的代碼發現那句loss一般是這樣寫
|
1
|
loss_sum += loss.data[0] |
這是因為輸出的loss的數據類型是Variable。而PyTorch的動態圖機制就是通過Variable來構建圖。主要是使用Variable計算的時候，會記錄下新產生的Variable的運算符號，在反向傳播求導的時候進行使用。如果這里直接將loss加起來，系統會認為這里也是計算圖的一部分，也就是說網絡會一直延伸變大那么消耗的顯存也就越來越大。
用Tensor計算要寫成：
|
1
2
3
4
|
train_loss += loss.item()correct_total += torch.eq(predict, label_batch).sum().item()train_loss += loss.item() |
當需要將模型中變量提取出來參與計算時，需要使用** .item()**
補充：linux下運行pytorch程序顯示“killed”或者“已殺死”
這是由pytorch對于內存不足的反應，確切說，是Linux內核對pytorch程序占用太多內存的反應。Linux內核一旦因為內存資源不足而生氣的時候，會使用OOM killer將占用內存最多的進程殺掉。
這種情況下，pytorch的python程序根本就來不及顯示相關的內存日志，直接在呼喊出killed這一個簡短有力的詞語后，就game over了。如果不提前掌握這個背景的話，你可真是會手足無措啊。
既然我們確定了是內存不足導致的問題（dmesg也能明確的顯示出kernel把占了近10個GB的python進程給kill了），
那我們的解決方案就有2個：
第一個是加大內存，將我的x99平臺的內存從16GB增加到64GB；這個方案先放棄了，因為內存條漲價太猛，我買不起了；
第二個是增加swap分區，當然性能會降低，但不需要額外增加成本。所以Gemfield今天的選擇就是第二個方案。
1、先禁止掉swap功能
|
1
|
sudo swapoff /swapfile |
這個命令執行之后，如果你用free命令查看的話會發現swap分區的大小變為了0。
2、增加 /swapfile的大小
|
1
|
sudo dd if=/dev/zero of=/swapfile bs=1M count=30720 oflag=append conv=notrunc |
這個命令會在現有的/swapfile后面追加30GB，加上之前的2GB的swap分區，現在共有32個GB的swap分區了。如果按照固態硬盤128GB有300多塊錢來算的話，這個命令花了七八十塊錢呢。
3、設置這個文件為swap分區的掛載點：
|
1
|
sudo mkswap /swapfile |
4、再次啟用swap
|
1
|
sudo swapon /swapfile |
以上為個人經驗，希望能給大家一個參考，也希望大家多多支持服務器之家。
原文鏈接：https://blog.csdn.net/qq_35899290/article/details/103549280
