Azure App Service内存交换时Hangfire未完成作业是否重启及交换原因

1. 传入Cancellation.None后未完成的作业是否会重启？ #

传入Cancellation.None只是让Hangfire不会主动触发作业的取消逻辑，但无法阻止外部因素（比如App Service进程因内存交换被强制回收）导致的作业中断。这种情况下作业是否重启，完全取决于你为Hangfire作业配置的重试规则：

• 如果作业设置了重试次数（默认可能带有重试策略，具体看你的配置），未完成的作业会被标记为失败，并按照设定的重试策略进入重试队列，自动重启。
• 如果没有配置重试，作业会直接被标记为失败状态，不会自动重启。

2. 内存交换的原因是什么？ #

Azure App Service中出现物理内存与CPU交换（内存分页到磁盘），核心原因是应用进程占用的内存超过了当前实例的配额上限：

• 不同定价层的App Service实例有固定的内存阈值，比如免费层、共享层内存配额极低，标准层及以上配额更高。当你的Hangfire长时运行进程持续占用内存，触碰到这个阈值时，操作系统会把部分内存数据写入磁盘的页面文件，释放物理内存供系统维持运行。
• 此外，应用存在内存泄漏、CPU持续高负载导致内存占用激增，或者App Service的定期应用池回收（默认29小时）、基于内存阈值的自动回收，也会触发临时的内存资源调整，伴随内存交换行为。

3. 这是否属于可干预的负载均衡机制？ #

内存交换本身不是负载均衡机制，它是单实例操作系统层面的资源自救手段，目的是在内存不足时避免进程直接崩溃。但你可以通过多种方式干预，减少甚至避免内存交换的发生：

• 升级App Service定价层，获取更大的内存配额，从根源上缓解内存压力。
• 优化Hangfire作业：拆分长时作业为多个短作业，降低单作业的内存占用；及时释放作业中不再使用的资源（比如数据库连接、大对象）。
• 调整App Service回收规则：在Azure门户中配置应用池的内存回收阈值，避免因内存超限触发强制回收。
• 启用自动缩放：根据CPU、内存使用率自动添加实例，分散负载，降低单个实例的资源压力。

内容的提问来源于stack exchange，提问作者Wilco Hendriksen