如何解决Celery ForkPoolWorker-1进程触发signal 9 (SIGKILL)退出报错

Process 'ForkPoolWorker-1' pid:xxxx exited with 'signal 9 (SIGKILL)' 是Celery prefork工作池的子进程被操作系统强制杀死的典型报错，信号9无法被进程自身捕获，不存在代码层面捕获异常的可能。结合小PDF生成正常、大体积带图片PDF触发报错的特征，99%的诱因是PDF渲染过程中worker进程内存占用超过阈值，被Linux OOM Killer、容器OOM机制强制回收。

• 先实锤OOM问题：执行命令dmesg -T | grep -i 'killed process'，如果输出中能找到对应pid的worker进程记录，且日志标注了out of memory字样、记录了进程被杀时的内存占用，即可确认是内存溢出导致。容器部署场景直接查看容器状态，出现OOMKilled标记即可实锤。
• 复现过程中监控内存：启动Celery worker后用top -p <worker主进程PID>，按H切换到子进程视图，观察大PDF生成任务执行时，对应处理任务的子进程内存涨幅，确认内存峰值是否触达系统/容器的内存上限。
• 核查xhtml2pdf渲染逻辑：xhtml2pdf渲染时会将全量HTML文本、所有嵌入的图片资源全部加载到内存中处理，无磁盘流式分片机制。如果HTML中嵌入的是未压缩的高分辨率原图，图片转PDF对象时内存会膨胀10倍以上（单张4000*3000分辨率的无压缩图片加载到内存就需要占用近48MB内存，20张图仅图片部分就占近1G内存，叠加文本渲染、PDF结构生成的开销很容易触达内存阈值）。
• 核查Celery配置问题：如果配置了过大的任务预取数、未配置子进程最大任务数，多个大PDF任务会被调度到同一个子进程处理，内存占用叠加；另外fork模式下如果父进程提前加载了大体积全局对象（比如全量缓存的字典、未释放的大结果集ORM查询），会触发写时复制机制额外占用内存。

• 优先优化xhtml2pdf渲染环节的内存占用
  • 所有嵌入PDF的图片提前做预处理：按PDF实际显示尺寸裁剪分辨率，非透明图一律转成70-80质量的JPG格式，禁止直接把几MB甚至几十MB的原始高分辨率图直接写入HTML模板。
  • 超过50页的大文档不要拼成单个HTML字符串一次性渲染，拆成多个分段渲染后再做PDF合并，避免单进程持有全量文档的内存开销。
  • 如果xhtml2pdf优化后内存占用还是过高，替换为内存控制更好的渲染库，同配置下WeasyPrint的渲染内存占用比xhtml2pdf低30%左右，百页以上大文档表现差距更明显。
• 调整Celery配置隔离大资源任务
  • 给PDF生成类的重资源任务单独配置专用队列、独立部署worker，不要和普通短任务共用worker池。专用worker配置--max-tasks-per-child=1，每处理完1个PDF任务就自动销毁重建子进程，彻底释放内存，避免内存残留叠加。
  • 专用worker设置worker_prefetch_multiplier = 1，关闭多任务预取，保证单个worker子进程同一时间只处理1个PDF任务，避免多任务内存叠加。
  • 容器化部署时，专用worker的内存上限按待生成最大PDF体积的10-15倍配置（比如最大生成100MB的PDF，给容器分配1.5G内存即可覆盖峰值开销）。
• 兜底方案：针对百页以上的超大型PDF，把全量生成逻辑拆成多步分片任务，每生成一部分就把中间结果落磁盘，不要把全量内容存在内存中，通过任务串联完成全量PDF生成后再返回结果。

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