Tensorflow 对象检测训练被杀死，资源匮乏？
Tensorflow Object Detection Training Killed, Resource starvation?
这个问题已经部分被问到 here and 没有后续行动，所以也许这不是问这个问题的地方，但我已经找到了一些我希望可能会的信息得到这些问题的答案。
我一直在尝试在我自己的大约 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
好的，所以在调查并尝试了一些事情之后，问题最终出现在我发布的 Dmesg 信息中。
训练占用的内存超过了我拥有的 8 GB，因此最终解决方案是 using Swap space 以增加模型必须拉取的内存量来自.
我遇到了和你一样的问题。实际上，内存被完全使用是由 data_augmentation_options ssd_random_crop 引起的，因此您可以删除此选项并将批处理大小设置为 8 或更小，即 2、4。当我设置batch size为1时，我也遇到了一些由nan loss引起的问题。
还有就是参数epsilon应该是一个很小的数，比如"deep learning"书上说的1e-6。因为epsilon是用来避免零分母的，但是这里的默认值是1，我觉得设置成1是不对的。
这是个问题many people face。有多个建议的解决方案：
- 减少批量大小——并不总是相关的，特别是如果你在 GPU 上训练（你应该这样做）
- 增加您的内存——按照您的建议，通过添加更多内存或使用交换内存。但是，如果您使用交换，请注意它比 RAM 慢 10-100 倍，因此一切都可能需要更长的时间
- Best: decrease queue sizes -- 注意到这个问题通常与模型没有直接关系，而是与配置有关。默认队列大小有点太大，因为模型的计算量很大并且不会高速处理示例。
我认为第三种解决方案最适合您，因为您 CPU 内存 (RAM) 已 运行。而且它不会减慢训练速度，也不会影响您的模型。
引用问题，加上我的评论：
The section in your new config will look like this:
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。
我被这个问题困扰了一段时间。我同意@Ciprian 的一系列步骤。我关注了他们所有人，结果发现我的情况与@Derek 的情况相似。我的问题通过扩展 Swap space.
解决了
对于陷入这个问题的人来说，只有几点要点，因为很难调试它在对象检测中的出现API，因为进程可能由于多种原因而被杀死。
- 使用以下 bash 脚本来监控 CPU 和 Swap space 的使用情况。您会发现，经过一定数量的步骤后，交换 space 耗尽，导致进程被终止。
watch -n 5 free -m
- 使用以下方法监控 GPU 的使用情况，以确保 GPU 没有被完全消耗。
nvidia-smi
- 如果以上步骤都没有发现问题，建议您不仅减少queue_capacity和min_after_dequeue ，还要在train_input_reader和中把num_readers改成1 eval_input_reader。除此之外，我建议使用 batch_queue_capacity、num_batch_queue_threads 和 prefetch_ queue_capacity 按照 this thread.
中的建议进一步减少 CPU 上的负载
将配置文件中的批量大小从 32 更改为 8 甚至 2。这肯定有助于训练并且不会终止进程。
这个问题已经部分被问到 here and
我一直在尝试在我自己的大约 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
好的，所以在调查并尝试了一些事情之后，问题最终出现在我发布的 Dmesg 信息中。
训练占用的内存超过了我拥有的 8 GB，因此最终解决方案是 using Swap space 以增加模型必须拉取的内存量来自.
我遇到了和你一样的问题。实际上，内存被完全使用是由 data_augmentation_options ssd_random_crop 引起的，因此您可以删除此选项并将批处理大小设置为 8 或更小，即 2、4。当我设置batch size为1时，我也遇到了一些由nan loss引起的问题。
还有就是参数epsilon应该是一个很小的数，比如"deep learning"书上说的1e-6。因为epsilon是用来避免零分母的，但是这里的默认值是1，我觉得设置成1是不对的。
这是个问题many people face。有多个建议的解决方案：
- 减少批量大小——并不总是相关的，特别是如果你在 GPU 上训练（你应该这样做）
- 增加您的内存——按照您的建议，通过添加更多内存或使用交换内存。但是，如果您使用交换，请注意它比 RAM 慢 10-100 倍，因此一切都可能需要更长的时间
- Best: decrease queue sizes -- 注意到这个问题通常与模型没有直接关系，而是与配置有关。默认队列大小有点太大，因为模型的计算量很大并且不会高速处理示例。
我认为第三种解决方案最适合您，因为您 CPU 内存 (RAM) 已 运行。而且它不会减慢训练速度，也不会影响您的模型。
引用问题，加上我的评论：
The section in your new config will look like this:
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。
我被这个问题困扰了一段时间。我同意@Ciprian 的一系列步骤。我关注了他们所有人，结果发现我的情况与@Derek 的情况相似。我的问题通过扩展 Swap space.
解决了对于陷入这个问题的人来说，只有几点要点，因为很难调试它在对象检测中的出现API，因为进程可能由于多种原因而被杀死。
- 使用以下 bash 脚本来监控 CPU 和 Swap space 的使用情况。您会发现，经过一定数量的步骤后，交换 space 耗尽，导致进程被终止。
watch -n 5 free -m
- 使用以下方法监控 GPU 的使用情况，以确保 GPU 没有被完全消耗。
nvidia-smi
- 如果以上步骤都没有发现问题，建议您不仅减少queue_capacity和min_after_dequeue ，还要在train_input_reader和中把num_readers改成1 eval_input_reader。除此之外，我建议使用 batch_queue_capacity、num_batch_queue_threads 和 prefetch_ queue_capacity 按照 this thread. 中的建议进一步减少 CPU 上的负载
将配置文件中的批量大小从 32 更改为 8 甚至 2。这肯定有助于训练并且不会终止进程。