异步任务报错-Celery: WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL)_task handler raised error: workerlosterror('worker

发现问题

使用celery异步任务时,异步任务开始但是未执行结束,查看日志报错:

分析原因

查找资料,有说是因为redis版本或者celery版本问题的,但是没有按照这个思路走下去,不能验证是否为这个原因,最后发现可能为内存问题, 因为之前mysql无法启动就是内存的问题,我使用的是运行内存为1G的服务器,运行django项目开了2个进程,安装有nginx redis celery supervisor进程管理工具,日常内存使用情况如下图

查找原因

在 stackoverflow 找到一篇博客说是内存问题,然后顺着思路找下去

解决办法

查看系统的内存日志文件发现这个
日志在这个文件 /var/log/messages
首先说一下这个文件的存在,在Ubuntu系统中,这个文件你访问可能提示找不到这个文件
关于ubuntu 日志文件查看的地址可以参考这个链接

然后查看了 oom 这个问题
可以看到， 这里会有oom和oom-killer的具体时间。 经我对比发现， 上述时间， 与系统发生异常报警的时间一致。 所以， 系统发生异常确实是由oom引起的。

oom就是out of memory, 意思就是内存用完了（内存泄漏可能导致这种现象）。 在linux中， 如果linux机器的内存用完了， 会怎样呢？ 很显然， 系统肯定无法正常工作。 linux当然要考虑这种问题， linux会杀死占用内存很大的进程（这些进程后续可能被重新拉取）， 从而释放出一些内存， 来保证整个系统的的正常运行, 这就是linux oom-killer的机制。
在oom期间， 系统经常会遇到一些莫名其妙的异常， 这是能理解的， 因为内存吃紧啊。 过一会儿， 经历oom-killer后， 系统又暂时恢复正常了， 待到下次内存泄漏积累到一定阶段， 再次出现oom时， 系统又异常。 这种现象是很常见的， 如果不了解oom和oom-killer, 则不太容易查到问题的原因
参考链接

这样大致就找到问题的原因所在了,具体的解决办法可以根据原因解决了:
查看是否为代码问题,出现内存泄漏
或者是更换更加大内存的服务器
根据自身原因寻找解决办法