尝试运行分布式 GCMLE 作业时遇到抢占操作系统错误

Posted

技术标签:

【中文标题】尝试运行分布式 GCMLE 作业时遇到抢占操作系统错误【英文标题】:Encountering preemption OS Error when trying to run distributed GCMLE job 【发布时间】:2019-03-18 13:34:17 【问题描述】:

我正在尝试运行分布式 GCMLE 训练作业,但我不断收到以下错误:

An error was raised. This may be due to a preemption in a connected worker or parameter server. The current session will be closed and a new session will be created. Error: OS Error

trainer 包是一个自定义估算器,其建模与cloudml-samples 人口普查自定义估算器:https://github.com/GoogleCloudPlatform/cloudml-samples/tree/master/census/customestimator/trainer 非常相似。可以肯定地说task.py 文件几乎相同,在model.py 文件中input_fn()parse_csv() 函数是相同的,唯一真正的区别在于我的model_fn() 的细节。

如果我将模型配置为使用单个 standard_p100 GPU 运行,我可以以约 15 步/秒的速度进行训练。但是,如果我将配置更新为具有 4 个工作人员和 3 个参数服务器的分布式设置(请参阅下面的配置),则会弹出抢占错误,并且 10 个步骤将需要大约 600 秒...

config-distributed.yaml:

trainingInput:
  scaleTier: CUSTOM
  masterType: standard_p100
  workerType: standard_p100
  parameterServerType: large_model
  workerCount: 3
  parameterServerCount: 3

如果我对人口普查自定义估计器样本使用相同的配置,则模型的训练速度会如预期的那样快,并且不会遇到抢占错误。我尝试修改人口普查示例以更接近地模仿我的确切代码,但仍然无法重现该错误。

在尝试训练分布式机器学习引擎作业时,是否有人遇到过类似的抢占问题?关于如何更好地调试问题的任何建议?我在网上找到的唯一建议是建议参数服务器的数量至少是工人数量的一半(这就是为什么我增加了 3 个参数服务器),但我仍然没有运气。

为了从日志中添加更多上下文,这是我尝试在分布式设置中训练时发生的典型(重复)模式:

master-replica-0 loss = 16.5019, step = 53 (124.505 sec)
master-replica-0 An error was raised. This may be due to a preemption in a connected worker or parameter server. The current session will be closed and a new session will be created. Error: OS Error
master-replica-0 Graph was finalized.
master-replica-0 Restoring parameters from gs://.../model.ckpt-0
master-replica-0 Running local_init_op.
master-replica-0 Done running local_init_op.
master-replica-0 Saving checkpoints for 0 into gs://...
master-replica-0 Skip the current checkpoint eval due to throttle secs (600 secs).
master-replica-0 An error was raised. This may be due to a preemption in a connected worker or parameter server. The current session will be closed and a new session will be created. Error: OS Error

然后这个循环重复......

更新

我将参数服务器的数量增加到 10 个,并且步数/秒在 5-10 之间跳跃(仅使用单个 GPU 时仍少于 15 个),错误仍然发生,但更零星一些。如果有更多的参数服务器有帮助,这意味着什么? CPU 和内存利用率非常低(

【问题讨论】:

我在某些数据集而不是其他数据集上遇到了同样的错误(我正在做对象检测)。你找到确切的来源了吗?我已将参数服务器的数量增加到 17 并不断收到错误消息。你至少弄清楚如何调试它了吗? 我认为错误在于我超出了网络带宽——我相信 GCMLE 网络带宽的上限为 2Gbps / cpu,最大为 16 Gbps。有人建议我在单个 VM 上运行多 GPU。 【参考方案1】:

具有大量参数的分布式训练的瓶颈通常是网络带宽。如果网络过度饱和,数据包会丢失,TensorFlow 会认为参数服务器已关闭。通过添加更多参数服务器,您可以分配网络负载。

请记住,如果您的模型适合使用 GPU,则通常在具有 8 个 GPU 的单台机器上而不是在具有单个 GPU 的 8 台机器上获得更好的吞吐量,因为您不会有任何网络开销。

【讨论】:

谢谢!这对于理解为什么增加参数服务器会有所帮助非常有帮助。你如何定义“适合使用 GPU”——这个模型使用卷积层、密集层和批量标准化(所以我认为它适合使用 GPU)。但是,如果我使用具有 8 个 GPU 的单台机器,我不会加快速度,因为我想我没有正确构建图表来使用 8 个塔中的每一个,等等——我承认我尝试过但未能做到这一点。作为一种需要较少代码更改的“更快”方法,我希望使用 8 台机器和一个 GPU 关于如何利用具有 8 个 GPU 的单台机器,您有什么资源可以推荐吗?是否有任何cloudml-samples 涉及创建可以跨多个 GPU 工作的“自定义估算器”?

以上是关于尝试运行分布式 GCMLE 作业时遇到抢占操作系统错误的主要内容,如果未能解决你的问题,请参考以下文章

gcloud 组件更新权限被拒绝

抢占式内核中,线程在系统调用过程中被抢占,然后又被重新调度时,如何返回至被中断的系统调用的

Datastream 开发打包问题

MapReduce作业调度

如何自动重启 GCE 抢占式实例?

keepalived的抢占与非抢占模式