GCP上的Python3 Pytorch RuntimeError - 没有消息答案

【问题标题】：Python3 Pytorch RuntimeError on GCP - no msgGCP上的Python3 Pytorch RuntimeError - 没有消息
【发布时间】：2021-01-29 01:09:13
【问题描述】：

我的系统

我正在使用 Python 3.6.9 和 pytorch 1.6.0 运行神经网络训练
我正在使用带有 Tesla T4、2 核 CPU、12GB RAM 的谷歌云平台 N1 服务器。这是在 Ubuntu 18.04 映像上。

问题

当我的代码到达训练行时，我得到以下RuntimeError，但我看不到任何真正的解释：

-- Process 0 terminated with the following error:
Traceback (most recent call last):
  File "/home/or/.local/share/virtualenvs/or-M3_AaJfY/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 20, in _wrap
    fn(i, *args)
  File "/home/or/my_model/train.py", line 88, in train_and_eval
    train(rank, epoch, hps, generator, optimizer_g, train_loader, logger, writer)
  File "/home/or/my_model/train.py", line 117, in train
    scaled_loss.backward()
  File "/home/or/.local/share/virtualenvs/or-M3_AaJfY/lib/python3.6/site-packages/torch/tensor.py", line 185, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph)
  File "/home/or/.local/share/virtualenvs/or-M3_AaJfY/lib/python3.6/site-packages/torch/autograd/__init__.py", line 127, in backward
    allow_unreachable=True)  # allow_unreachable flag
RuntimeError

当 2 个 CPU 内核长时间 100% 使用时会发生这种情况。
虽然 RAM 和 GPU 上升（如训练时预期的那样），但并未达到接近它们的限制。
我检查了journalctl，看看这是否是操作系统问题，但那里什么都没有。我也没有在 /var/log/ 目录或使用 dmesg 找到任何相关内容。
我很乐意提供更多日志数据，但我不知道（搜索后）我可以查看的任何 python 日志或任何其他系统日志。

如果您有任何想法，请告诉我如何获取更多信息。

完全相同的代码在我测试过的其他物理机器上可以 100% 正常运行，而它的仅 GPU 版本在其他云计算提供商上也可以正常运行

我在寻找什么

获取有关此问题的更多信息并找出其发生原因的方法。
解决此问题的方法

提前感谢您抽出宝贵时间以及您可能提供的任何帮助。

【问题讨论】：

标签： python-3.x tensorflow google-cloud-platform neural-network pytorch

【解决方案1】：

Anthony Leo 非常感谢您的详细回答！不幸的是，这最终成为我在设置服务器时安装的模块之一的问题。
这最终不是服务器本身或我的代码的问题，我只是在设置时错误地安装了一个模块。

对于其他人在此问题上花费的所有时间，我深表歉意。

【讨论】：

【解决方案2】：

在寻找方法来获取有关该问题的更多信息以找出此问题发生的原因。您可以将故障排除分为两层：

应用层
GCE 虚拟机实例层

在大多数情况下，我们将专注于查看 GCE 虚拟机实例层，因为在此位置可以找到更多信息，因为这些日志将向我们显示 GCE 实例是否在之前或之后遇到问题的信息您在上面介绍的堆栈跟踪。

根据您的虚拟机实例配置，建议在受影响的虚拟机上安装Cloud Logging Agent，以便我们可以从虚拟机内部收集日志。这也很有帮助，因为收集的这些日志是准确的。

在虚拟机上安装并运行代理后，我们可以将自己定向到 GCP 上的 Logs Explorer 控制台，这将允许我们查看上述层中的两种类型的日志。请记住，通过此步骤，您应该重新运行您的应用程序及其场景。

从这里开始，我们可以使用logs queries 查看所有日志并根据Logs Explorer 中的时间戳、资源类型等对它们进行排序。这将是一个很好的起点，因为它允许您按照导致错误的日志按时间顺序查看所有日志。这应该可以让您找出发生此问题的原因和/或提供如何解决此问题的线索。

【讨论】：