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的動(dòng)態(tài)圖機(jī)制就是通過Variable來構(gòu)建圖。主要是使用Variable計(jì)算的時(shí)候,會(huì)記錄下新產(chǎn)生的Variable的運(yùn)算符號(hào),在反向傳播求導(dǎo)的時(shí)候進(jìn)行使用。如果這里直接將loss加起來,系統(tǒng)會(huì)認(rèn)為這里也是計(jì)算圖的一部分,也就是說網(wǎng)絡(luò)會(huì)一直延伸變大那么消耗的顯存也就越來越大。
train_loss += loss.item() correct_total += torch.eq(predict, label_batch).sum().item() train_loss += loss.item()
當(dāng)需要將模型中變量提取出來參與計(jì)算時(shí),需要使用** .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)存資源不足而生氣的時(shí)候,會(huì)使用OOM killer將占用內(nèi)存最多的進(jìn)程殺掉。
這種情況下,pytorch的python程序根本就來不及顯示相關(guān)的內(nèi)存日志,直接在呼喊出killed這一個(gè)簡短有力的詞語后,就game over了。如果不提前掌握這個(gè)背景的話,你可真是會(huì)手足無措啊。
既然我們確定了是內(nèi)存不足導(dǎo)致的問題(dmesg也能明確的顯示出kernel把占了近10個(gè)GB的python進(jìn)程給kill了),
第一個(gè)是加大內(nèi)存,將我的x99平臺(tái)的內(nèi)存從16GB增加到64GB;這個(gè)方案先放棄了,因?yàn)閮?nèi)存條漲價(jià)太猛,我買不起了;
第二個(gè)是增加swap分區(qū),當(dāng)然性能會(huì)降低,但不需要額外增加成本。所以Gemfield今天的選擇就是第二個(gè)方案。
sudo swapoff /swapfile
這個(gè)命令執(zhí)行之后,如果你用free命令查看的話會(huì)發(fā)現(xiàn)swap分區(qū)的大小變?yōu)榱?。
sudo dd if=/dev/zero of=/swapfile bs=1M count=30720 oflag=append conv=notrunc
這個(gè)命令會(huì)在現(xiàn)有的/swapfile后面追加30GB,加上之前的2GB的swap分區(qū),現(xiàn)在共有32個(gè)GB的swap分區(qū)了。如果按照固態(tài)硬盤128GB有300多塊錢來算的話,這個(gè)命令花了七八十塊錢呢。
sudo mkswap /swapfile
sudo swapon /swapfile
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
標(biāo)簽:江蘇 山東 駐馬店 蘭州 宿遷 常州 成都 六盤水
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《解決Pytorch內(nèi)存溢出,Ubuntu進(jìn)程killed的問題》,本文關(guān)鍵詞 解決,Pytorch,內(nèi)存,溢出,Ubuntu,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。