TensorFlow 目标检测训练被杀，资源匮乏？答案

【问题标题】：Tensorflow Object Detection Training Killed, Resource starvation?TensorFlow 目标检测训练被杀，资源匮乏？
【发布时间】：2017-07-17 18:01:24
【问题描述】：

这个问题部分被问到here 和here 没有后续行动，所以也许这不是问这个问题的地方，但我想出了更多的信息，我希望可能得到这些问题的答案。

我一直在尝试在我自己的大约 1k 张照片库上训练 object_detection。我一直在使用提供的管道配置文件“ssd_inception_v2_pets.config”。我相信我已经正确设置了训练数据。该程序似乎开始训练就好了。当它无法读取数据时，它会发出错误警报，我修复了它。

我的 train_config 设置如下，但我更改了一些数字以尝试让它以更少的资源运行。

train_config: {
  batch_size: 1000 #also tried 1, 10, and 100
  optimizer {
    rms_prop_optimizer: {
      learning_rate: {
        exponential_decay_learning_rate {
          initial_learning_rate: 0.04  # also tried .004
          decay_steps: 800 # also tried 800720. 80072
          decay_factor: 0.95
        }
      }
      momentum_optimizer_value: 0.9
      decay: 0.9
      epsilon: 1.0
    }
  }
  fine_tune_checkpoint: "~/Downloads/ssd_inception_v2_coco_11_06_2017/model.ckpt" #using inception checkpoint
  from_detection_checkpoint: true
  data_augmentation_options {
    random_horizontal_flip {
    }
  }
  data_augmentation_options {
    ssd_random_crop {
    }
  }
}

基本上，我认为正在发生的事情是计算机很快就会资源匮乏，我想知道是否有人进行了优化，需要更多时间来构建但使用更少的资源？

或者我错了为什么进程被杀死，有没有办法让我从内核中获取更多信息？

这是我在进程被杀死后得到的Dmesg信息。

[711708.975215] Out of memory: Kill process 22087 (python) score 517 or sacrifice child
[711708.975221] Killed process 22087 (python) total-vm:9086536kB, anon-rss:6114136kB, file-rss:24kB, shmem-rss:0kB

【问题讨论】：

标签： tensorflow linux-kernel protocol-buffers object-detection training-data

【解决方案1】：

我遇到了和你一样的问题。实际上，内存已满是由data_augmentation_options ssd_random_crop 引起的，因此您可以删除此选项并将批量大小设置为8 或更小，即2,4。当我将批量大小设置为 1 时，我也遇到了一些由 nan loss 引起的问题。

还有一点就是参数epsilon应该是一个很小的数，比如根据《深度学习》一书的1e^-6。因为epsilon是用来避免分母为零的，但是这里的默认值是1，我觉得设置为1是不对的。

【讨论】：

欢迎来到 Stack Overflow！我对您的答案进行了一些小的格式编辑 - 这在社区中是完全正常的，而不是批评。 :)

【解决方案2】：

好的，所以在调查并尝试了一些事情之后，问题最终出现在我发布的 Dmesg 信息中。

训练占用的内存超过了我拥有的 8 GB 内存，因此最终解决方案是 using Swap 空间，以增加模型必须从中提取的内存量。

【讨论】：

【解决方案3】：

这是一个问题many people face。有多种建议的解决方案：

减少批量大小 - 并不总是相关的，尤其是如果您在 GPU 上进行训练（您应该这样做）
按照您的建议，通过添加更多或使用交换来增加内存。但是，如果您使用交换，请注意它比 RAM 慢约 10-100 倍，因此一切可能需要更长的时间
最佳： decrease queue sizes -- 注意到通常此问题与模型没有直接关系，而是与配置有关。默认队列大小有点过大，因为模型计算量很大，并且不能高速处理示例。

我相信第三种解决方案最适合您，因为您的 CPU 内存 (RAM) 已用完。而且它不会减慢训练速度，也不会影响您的模型。

用我的 cmets 引用这个问题：

新配置中的部分将如下所示：

train_input_reader: { tf_record_input_reader { input_path: "PATH_TO_BE_CONFIGURED/pet_train.record" } label_map_path: "PATH_TO_BE_CONFIGURED/pet_label_map.pbtxt" queue_capacity: 500 # change this number min_after_dequeue: 250 # change this number (strictly less than the above) }

您也可以为eval_input_reader 设置这些。对于这个我使用20, 10 和train 我使用400, 200，虽然我认为我可以降低。我的训练占用不到 8Gb 的 RAM。

【讨论】：

【解决方案4】：

一段时间以来，我一直受到这个问题的困扰。我同意@Ciprian 的一系列步骤。我跟着他们所有人，结果发现我的情况与@Derek 的情况相似。扩展Swap空间解决了我的问题。

对于陷入此问题的人来说只有几点，因为很难在对象检测 API 中调试它的发生，因为进程可能由于多种原因而被终止。

使用以下 bash 脚本监控 CPU 和交换空间的使用情况。您会发现经过一定数量的步骤后，交换空间会耗尽，导致进程被终止。

看 -n 5 免费 -m

使用以下内容监控 GPU 的使用情况，以确保 GPU 没有被完全消耗。

nvidia-smi

如果您在上述任何步骤中都没有发现问题，我建议您不仅减少 queue_capacity 和 min_after_dequeue，还可以更改 num_readers train_input_reader 和 eval_input_reader 中的 em> 为 1。除此之外，我建议使用 batch_queue_capacity、num_batch_queue_threads 和 prefetch_queue_capacity 以进一步减少 CPU 的负载，如 this thread 中所建议的那样.

【讨论】：

【解决方案5】：

将配置文件中的批量大小从 32 更改为 8 甚至 2。这肯定有助于训练并且不会终止进程。

【讨论】：