pytorch顯存越來越多的一個原因

optimizer.zero_grad()
loss.backward()
optimizer.step()
train_loss += loss

參考了別人的代碼發(fā)現(xiàn)那句loss一般是這樣寫

loss_sum += loss.data[0]

這是因?yàn)檩敵龅膌oss的數(shù)據(jù)類型是Variable。而PyTorch的動態(tài)圖機(jī)制就是通過Variable來構(gòu)建圖。主要是使用Variable計算的時候，會記錄下新產(chǎn)生的Variable的運(yùn)算符號，在反向傳播求導(dǎo)的時候進(jìn)行使用。如果這里直接將loss加起來，系統(tǒng)會認(rèn)為這里也是計算圖的一部分，也就是說網(wǎng)絡(luò)會一直延伸變大那么消耗的顯存也就越來越大。

用Tensor計算要寫成：

train_loss += loss.item()

correct_total += torch.eq(predict, label_batch).sum().item()
train_loss += loss.item()

當(dāng)需要將模型中變量提取出來參與計算時，需要使用** .item()**

補(bǔ)充：linux下運(yùn)行pytorch程序顯示“killed”或者“已殺死”

這是由pytorch對于內(nèi)存不足的反應(yīng)，確切說，是Linux內(nèi)核對pytorch程序占用太多內(nèi)存的反應(yīng)。Linux內(nèi)核一旦因?yàn)閮?nèi)存資源不足而生氣的時候，會使用OOM killer將占用內(nèi)存最多的進(jìn)程殺掉。

這種情況下，pytorch的python程序根本就來不及顯示相關(guān)的內(nèi)存日志，直接在呼喊出killed這一個簡短有力的詞語后，就game over了。如果不提前掌握這個背景的話，你可真是會手足無措啊。

既然我們確定了是內(nèi)存不足導(dǎo)致的問題（dmesg也能明確的顯示出kernel把占了近10個GB的python進(jìn)程給kill了），

那我們的解決方案就有2個：

第一個是加大內(nèi)存，將我的x99平臺的內(nèi)存從16GB增加到64GB；這個方案先放棄了，因?yàn)閮?nèi)存條漲價太猛，我買不起了；

第二個是增加swap分區(qū)，當(dāng)然性能會降低，但不需要額外增加成本。所以Gemfield今天的選擇就是第二個方案。

1、先禁止掉swap功能

sudo swapoff /swapfile

這個命令執(zhí)行之后，如果你用free命令查看的話會發(fā)現(xiàn)swap分區(qū)的大小變?yōu)榱?。

2、增加 /swapfile的大小

sudo dd if=/dev/zero of=/swapfile bs=1M count=30720 oflag=append conv=notrunc

這個命令會在現(xiàn)有的/swapfile后面追加30GB，加上之前的2GB的swap分區(qū)，現(xiàn)在共有32個GB的swap分區(qū)了。如果按照固態(tài)硬盤128GB有300多塊錢來算的話，這個命令花了七八十塊錢呢。

3、設(shè)置這個文件為swap分區(qū)的掛載點(diǎn)：

sudo mkswap /swapfile

4、再次啟用swap

sudo swapon /swapfile

以上為個人經(jīng)驗(yàn)，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論