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
