上传4GB以上镜像至AWS ECR时Django Q Worker异常重启问题

场景描述 #

前端将.tar文件发送至后端，后端接收该文件的二进制数据后，启动Django Q并通过其将镜像逐层上传至AWS ECR。

当前Django Q集群配置 #

Q_CLUSTER = {
  "name": "abc",
  "workers": 8,
  "recycle": 500,
  'attempt_count': 1,
  'ack_failures': True,
  "compress": True,
  "save_limit": 250,
  "queue_limit": 500,
  "cpu_affinity": 1,
  "label": "Django Q",
  "redis": {
      "host": REDIS_HOST,
      "port": REDIS_PORT,
      "db": 0,
  },
}

遇到的问题 #

• 部分镜像层推送完成后，Worker进程Process-1:4死亡并被自动重启
• 无法上传大于4GB的镜像
• 已尝试设置attempt_count=1和ack_failures=True，问题仍未解决

上传日志 #

[INFO] Starting pushing layer 66ffede0daa0486a61c11446bcb954ad89df6c2cb567ecd6ab97c12228ef6e8f/layer.tar
[INFO] Upload started

[INFO] Starting pushing layer 4562d7acfd41cfad11b031cdd9bcd217dcd3cd36fd0cc5aabfc8df18e3a6972b/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer bacd26a46504a4282343e37dac8ac4c24ee649fe85c605547d57960822e076fe/layer.tar
[INFO] Upload started
Pushing... 100.0%  

[INFO] Starting pushing layer 29165659eb61efe28b84e580bdca126a60a356655dd62a6bed38d61a496fa6aa/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer 50e432f951ede2c9c9c299f8a68e106282af2f59fdf1120ec9cc084a1005da22/layer.tar
[INFO] Upload started
Pushing... 100.0%  
[INFO] Starting pushing layer dc984c3c30a1a444dfdfcdff0686ef712412716920ad8fe619787f7735ab156e/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer fe6d7993f09d1b294ae3980f370e0b9b434941bfa99c85a3c63428c0f6a1a2e7/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer b561779bae7406e1a97dae43f3c0b45e5dd8a52d359aae533e670775cb0464df/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer 170d1e7a28c707797b61f0f54c14f5ad2cff239855a823e3c2442ef09adf0ab5/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer f521d5101bf2325bb2e210dbd9c86c1608ab083c4f2d819cf8bc205810492474/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer 2908c3588dbe82e5eaac1f06a0b3a5d60b7d689d489c28d3c95b310c23d18bd2/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer 27bcf483885811cb8ee15fd784cf8115910a78505fd98f54d013b14cf7b0b923/layer.tar
[INFO] Upload started
[INFO] Starting pushing layer 4d19ecbd1fbd26168147a173d7085150b661957dd7244fe154f1f48efd53302f/layer.tar
[INFO] Upload started
Pushing... 100.0%  
Pushing... 100.0%  
Pushing... 100.0%  


Pushing... 100.0%  
Pushing... 100.0%  
Pushing... 100.0%  
Pushing... 100.0%  
10:43:00 [Q] ERROR reincarnated worker Process-1:4 after death
10:43:00 [Q] INFO Process-1:11 ready for work at 50

解决建议 #

1. 排查内存溢出问题 #

• 降低Worker数量：当前workers=8，若服务器内存资源有限，减少到4或更低，避免多进程同时处理大文件导致内存耗尽。
• 调整进程回收频率：将recycle从500调小至100，让Worker进程更频繁重启，及时释放内存。
• 监控内存使用：上传时用top或ps aux命令查看Worker进程的内存占用，确认是否被系统OOM Killer终止。

2. 优化大文件处理流程 #

• 避免内存加载大文件：后端接收.tar文件时，直接保存到本地磁盘，不要一次性加载到内存；Django Q任务从磁盘读取文件进行分层处理。
• 使用流式上传：调用AWS ECR接口时，使用boto3的upload_fileobj等流式上传方法，分块上传镜像层，避免一次性加载整个层到内存。

3. 调整Django Q配置 #

• 关闭压缩：将compress=True改为compress=False，压缩大文件会额外消耗CPU和内存，可能加剧进程崩溃问题。
• 检查Redis资源：确保Redis有足够内存存储任务数据，大任务的序列化数据可能占用较多Redis内存，导致任务处理异常。

4. 完善错误捕获与日志 #

• 在Django Q的任务函数中添加完整的异常捕获逻辑，记录详细错误信息（如内存错误、AWS API异常等），明确进程崩溃的具体原因。
• 可通过系统工具（如ulimit）限制Worker进程的内存上限，防止单个进程占用过多资源影响集群。

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