PythonAnywhere上Flask应用Loguru启用enqueue致uWSGI Worker崩溃排查

• 信号9的核心原因：内存超限被系统强制终止
  信号9（SIGKILL）是操作系统在进程占用内存超过配额时的强制终止手段，PythonAnywhere的Hacker级别账户有严格的内存限制。这种情况下进程会被直接杀死，来不及生成应用层的错误日志（包括404），和你观察到的现象完全匹配。

• Loguru enqueue=True的额外内存开销
  启用enqueue时，Loguru会启动独立的后台进程处理日志队列，同时每个uWSGI Worker进程都会维护自己的日志消息队列。高负载下，大量未处理的日志消息会积压在队列中，加上后台进程本身的内存占用，会快速突破PythonAnywhere的内存配额。而enqueue=False时，日志是同步写入，没有队列积压和额外后台进程的内存消耗，内存占用保持稳定。

• uWSGI多进程环境的叠加效应
  PythonAnywhere默认用多Worker模式运行uWSGI，每个Worker都会触发Loguru的enqueue机制，要么各自启动后台进程，要么共享队列时产生额外的内存开销。高负载下多个Worker的队列同时积压，内存用量呈倍数级上升，直接触发系统的OOM Killer（内存不足杀手），导致Worker被SIGKILL终止。

• 受限环境的隐性问题
  这种情况在本地测试时可能不会出现（因为本地内存充足），但PythonAnywhere的Hacker账户资源限制严格，Loguru enqueue机制的隐性内存增长会被快速触发，进而引发进程崩溃。

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