提升AWS服务器内存是否可以解决Celery出现的SIGKILL报错问题

WorkerLostError 抛出信号9（SIGKILL）本质是Linux系统的OOM（Out of Memory）杀手进程主动终止了内存占用超出系统阈值的Celery worker进程，和你查到的内存不足/泄漏、交换分区异常的原因吻合。

需要分场景判断：

• 若你的单任务运行内存峰值本身就超过4GB，且不存在内存泄漏问题：本地16GB内存足够支撑任务跑完全程，搬迁到4GB服务器后内存配额不足，这种场景升级AWS服务器内存可以直接解决问题，建议升级到内存大小高于你单任务峰值内存2GB以上的配置，预留系统运行的冗余空间。
• 若任务代码存在内存泄漏：比如长任务运行过程中持续累积未释放的大对象、全局缓存无过期清理逻辑、Celery worker无自动重启机制，升级内存只会延缓进程被杀的时间，8-10小时的长任务最终还是会耗完全部内存被终止，这种场景升级内存无法彻底解决问题。

• 先定位根因：任务运行期间执行free -h、top命令查看内存占用趋势，或者通过AWS CloudWatch的服务器内存监控指标判断：
  • 内存占用上升到某一阈值后保持稳定，属于内存配额不足，直接升级内存即可。
  • 内存占用全程持续线性上涨无平稳趋势，属于内存泄漏，优先排查代码中未释放的内存占用点。
• 长任务场景Celery配置优化：
  • 给Celery worker添加--max-tasks-per-child=1参数，让单个worker执行完1个长任务后自动重启，主动释放占用的内存，就算存在少量内存泄漏也可以被周期性清理。
  • 2核4GB服务器不要配置过高的worker并发数，建议先从单worker单并发测试，确认单任务内存占用后再调整并发数，避免多任务并行抢占内存。
• 临时兜底方案：如果暂时无法升级配置或者排查问题，可以给服务器开启交换分区（Swap），用磁盘空间虚拟内存，避免进程直接被OOM杀死，缺点是磁盘读写速度远低于内存，任务运行速度会变慢。

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