【发布时间】:2016-10-07 18:46:45
【问题描述】:
我希望使用 API 来根据处理 Q 的大小更改我正在运行的 Web 作业实例的数量,我知道我可以在门户中设置规则,但最短聚合时间是 60 分钟,我如果我们突然收到大量工作,不希望系统在扩大规模之前等待 60 分钟。
我遇到的问题是,目前如果我在门户中手动从 1 个实例扩展到 5 个实例,它会杀死单个正在运行的实例,然后启动 5 个新实例。
我假设如果我通过 API 执行此操作,也会发生同样的事情,您知道是否有任何方法可以避免这种情况?
谢谢
硅
更新: 见下文,我提交了 4 个作业,然后在第一个正在处理时,我从 1 个实例扩展到 3 个实例,这就是发生的事情,Never Finished 然后在接下来的 3 个完成后重新运行的作业,因为它的消息会弹出回来队列,因为它最初处理失败。
【问题讨论】:
-
我知道这不是您问题的直接答案,但您可能想看看 Azure Functions。
-
@4c74356b41 嗨,我只是查看了函数,但网络作业非常繁重,我怀疑 1.5GB 内存限制可能会阻止我们将应用程序转换为函数。问题是我不确定 webjob 属性中的哪个内存设置是要考虑的,请参阅上面的更新了解内存详细信息。
-
我相信工作集是你需要看的,虚拟内存是页面文件?但这是每个实例的数据吗?如果您几乎立即向外扩展(就像 azure 函数一样),您不能分散负载吗?
-
@4c74356b41 有趣的是,问题是我们要处理不同大小的文件,因此一个巨大的文件可能需要比当时允许的更多的内存,我的理解是函数死亡/停止。每个函数将处理一个文件,以避免文件大小成为问题,我想我们需要将内存密集型元素分解为它们自己的函数,这样我们就可以控制每个函数的处理量......这是一个公平的块重新架构虽然;-)
-
@4c74356b41 我想简单的测试是尝试将 webjob 转换为函数,然后在大文件上尝试一下,看看会发生什么!
标签: azure azure-webjobs