长时间运行的Azure Webjob - 经常停止

Question

长时间运行的Azure Webjob - 经常停止

6

我一直在使用Azure WebJobs，但仍然不知道为什么有些长时间运行的WebJob会失败...

我使用Azure SDK构建了一个WebJob，它会从队列消息中触发。这个WebJob会从Azure Blob存储中拉取一个包含110000个条目信息的XML文件，然后循环遍历这些信息，并使用REST WebApi2端点创建各种HttpClient请求，以在我们的表存储和DocumentDB中创建各种实体...这个过程非常缓慢，我正在努力解决这个问题，但需要运行数天...这没问题，因为没有紧急情况，除了它会随机停止，有时候只运行两天...上一次的唯一错误信息是“线程被中止”。我定期记录日志并进行http调用，因此工作不是无所事事的... 更新：

我还应该说明，我已经升级了整个应用程序服务计划到S1，并将托管WebJob的Web应用程序设置为始终开启（Always On）...

我还查看了“WEBJOBS_RESTART_TIME”，但这与重启停止后的操作无关，我认为一个没有错误的持续性作业不应该这样做！

- dreadeddev

2个回答

1

我们一直遇到长时间运行的Web作业问题，最终购买了付费支持，因为这些作业经常失败，而且我们无法弄清原因。这种情况已经持续了两个多月，仍然没有解决方案。他们建议使用local_cache设置，一段时间内停止了重启，但最终重启又开始了。

我们曾将它们从虚拟机上移走，而在那里运行顺畅了数年。我认为，Web作业并不适合长时间运行的作业，应该转移到虚拟机上。我们有许多短时间运行的作业，它们表现得很好，但对于任何长时间运行的作业，我认为Web作业还没有准备好。我们已经花了很多时间与支持团队解决这些问题，但毫无结果，坦率地说，我们觉得此时只是在浪费时间。自己免受痛苦，转向虚拟机，并在6个月后重新考虑。

- JonnyBravoJr

当你的生产系统每天多次失败，而你支付的支持无法解决问题时，等待会议的消息可能不是最佳策略。 - JonnyBravoJr

感谢您的评论，知道我不是唯一一个在这方面挣扎的人总是很有趣和奇怪的安慰。微软的指导方针是Web作业应该具有从我们离开的地方继续执行的能力，我想当你可能被协调到不同的资源之间时，这并不令人惊讶。一旦我将这个逻辑添加到我的工作中，那么它重新启动的事实实际上并不重要。我想当你这样看待它时，你的工作可能应该更加防御性地编程，以允许这种情况的发生。 - dreadeddev

自从我发布上述内容以来，我学到了一些东西：1）它们实际上并不经常移动您的Webapp/Webjob，因此作业失败很少是这种活动的迹象。支持技术人员告诉了我这一点。这让我相信，“从上次离开的地方继续”策略是微软处理潜在问题的方式。2）如果您不是高级客户，请不要费心购买支持，因为您真的不会得到太多帮助，除非您的问题是“我该如何”类型的问题。我们已将所有内容移回VM，并且一切都非常稳定，因此我们知道这不是我们的代码的问题... - JonnyBravoJr

我们实际上已经转移到了AWS。虽然他们没有Webjobs /应用程序，但支持非常好，他们帮助我们解决了一些小问题。我们从未能够使Azure中的作业停止失败，而支持只会告诉我们“我们正在努力”，但从未发生任何事情。也许现在情况已经改善，长时间运行的作业是稳定的，但我们目前不考虑回到Azure。 - JonnyBravoJr

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matias Quaranta · Accepted Answer

针对运行时间较长的Webjobs，我发现有一点需要注意。为了让线程能够持续工作很长时间，你必须要：

每隔一段时间使用Console.Write向输出写入一些内容。
添加一个名为WEBJOBS_IDLE_TIMEOUT（来源）的应用程序设置，该设置定义了环境在关闭闲置Webjob（没有控制台输出）之前等待的时间。

我建议你两者都做，添加类似于“心跳”的Console.Write并添加应用程序设置。