【问题标题】:Azure Worker with webapi Role Unexpected Restart具有 webapi 角色的 Azure Worker 意外重启
【发布时间】:2016-03-31 18:15:35
【问题描述】:

我在 A7 Azure Worker 角色上有一个辅助角色。角色是一个 ASP Webapi。

当角色运行时,我可以向它发送一个命令(通过 Web 界面),该命令启动一个需要长达 8 小时的数据聚合过程。

此时创建了一个大对象图。

这工作了几个月,没有任何问题。

现在有时似乎角色或 api 在创建过程中重新启动。

有一次我能够在 azure 管理门户中观察到它,它看起来像这样:

但协议中没有重新启动。

【问题讨论】:

  • 您的数据聚合逻辑位于何处?在 Web API 层还是在单独的进程中?您是在工作人员角色中自托管 WebAPI,还是使用 IIS?我问是因为 IIS 不适合 8 小时的内存密集型工作负载。
  • 我们刚刚创建了一个带有默认 vs 项目模板的工作角色,不确定该配置是默认的
  • 您的 Web API 是在 worker 角色还是在 IIS 的 web 角色中运行? (azure.microsoft.com/en-us/documentation/articles/…) 如果它是一个真正的工作者角色,那么运行 8 小时任务是一个不错的选择,但您需要小心地将 Web API 层与长时间运行的逻辑分开(通常使用单独的角色 + 队列) .如果它是一个网络角色,那么这又不是运行 8 小时工作负载的地方。一般来说,我认为您需要正式地将 Web API 层与长期运行的逻辑分开。他们应该担任不同的角色。
  • 这是一个工人角色。
  • 如果您可以发布一些代码来展示您如何将 Web API 与您的工作角色集成以及您的 8 小时工作负载如何执行,这可能会有所帮助。或者也许只是进一步解释您的设计。我们需要更多细节来理解这个问题。

标签: azure asp.net-web-api azure-worker-roles


【解决方案1】:

我一直在联系 azure 支持。

结果是实例太小,无法处理如此庞大的数量。

我们切换到 D14 实例,一切正常

【讨论】:

  • 你能补充一些细节吗?您是否确实使用了过多的内存并且记录在案?如果内存是问题,它应该出现在您的仪表板中,并且非常容易注意到和跟踪。你是否发现你没有达到你的极限,但你的工人仍然不知何故崩溃了? A7 到 D14 每月要多花 500 美元,这是相当激烈的......
猜你喜欢
  • 2013-04-19
  • 2018-03-03
  • 1970-01-01
  • 1970-01-01
  • 2014-12-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-04-16
相关资源
最近更新 更多