在后台进程运行unstructured.partition_pdf时FastAPI无响应的原因及解决方案咨询

看起来你遇到的问题挺棘手的——明明把PDF解析逻辑放到了独立进程里，结果FastAPI还是被卡得动弹不得。我来帮你拆解一下可能的原因，以及对应的解决思路：

为什么子进程里的partition_pdf还是会阻塞FastAPI？ #

虽然你用了multiprocessing.Process避开了GIL，但有几个容易被忽略的点会导致主进程被拖慢：

1. 磁盘I/O资源耗尽
   你用的是strategy='hi_res'模式，这个模式下partition_pdf会对PDF做非常密集的磁盘读写（比如提取页面、处理图片、生成临时文件等）。如果是本地开发环境，磁盘通常是单通道的共享资源——当子进程在疯狂读写磁盘时，FastAPI主进程的I/O操作（比如读取请求体、写入日志、访问静态文件等）会被磁盘调度器阻塞，看起来就像主进程挂了一样。你之前用的os.nice是调整CPU优先级，对磁盘I/O的竞争没什么用。

2. CPU核心被完全占满
   哪怕是多核心机器，partition_pdf的hi_res策略可能会启动多个线程/子进程（比如调用Tesseract做OCR、用PDFPlumber解析页面），把所有CPU核心都占满。这时候FastAPI主进程的线程/进程抢不到CPU时间片，自然无法及时响应请求。你看到的是子进程在运行，但它可能在疯狂抢占所有核心资源。

3. unstructured内部的隐式资源共享（可能性较低）
   虽然你用了独立进程，但partition_pdf在hi_res模式下可能会用到一些全局的系统资源（比如临时目录、GPU资源如果有的话），或者某些依赖库（比如Poppler、Tesseract）本身存在进程间的资源竞争问题，间接影响主进程。

怎么解决才能让FastAPI真正不被影响？ #

这里给你几个递进的解决方案，从简单调整到架构优化：

1. 先优化资源竞争（快速试错） #

• 调整I/O优先级：用ionice命令给子进程设置更低的I/O优先级（比os.nice针对I/O更有效）。在子进程启动后，执行：

  import os
  os.system(f"ionice -c 3 -p {os.getpid()}")
  

  这个命令会让子进程只在磁盘空闲时才进行I/O操作，不会抢占主进程的磁盘资源。

• 限制CPU亲和性：让子进程只使用部分CPU核心，给FastAPI留足资源。比如在Linux/macOS下：

  import os
  from multiprocessing import cpu_count
  # 让子进程只使用除第一个核心外的其他核心（假设主进程用第一个）
  os.sched_setaffinity(0, range(1, cpu_count()))
  

  Windows下可以用win32process模块设置进程亲和性。

• 优化unstructured参数：如果业务允许，试试把strategy改成fast，这个模式的资源消耗会低很多，对主进程的影响也小。如果必须用hi_res，可以减少max_characters或者关闭infer_table_structure（这个选项会大幅增加CPU和I/O消耗）。

2. 用异步任务队列彻底隔离（长期方案） #

上面的优化都是“缓解”，如果要彻底让PDF解析和FastAPI完全解耦，最好用独立的任务队列系统，比如Celery + Redis/RabbitMQ：

• 步骤：

  1. 把PDF解析逻辑包装成Celery任务。
  2. FastAPI收到请求后，把任务参数丢到任务队列，立刻返回一个“任务已提交”的响应（比如返回任务ID，方便前端查询状态）。
  3. 启动独立的Celery Worker进程（和FastAPI完全分离）来处理队列里的PDF解析任务。
     这样即使Worker进程把CPU/磁盘占满，FastAPI主进程只负责接收请求和返回响应，完全不受影响。

  示例Celery任务大概是这样的：

  # celery_app.py
  from celery import Celery
  from unstructured.partition.pdf import partition_pdf
  
  celery_app = Celery('pdf_tasks', broker='redis://localhost:6379/0', backend='redis://localhost:6379/0')
  
  @celery_app.task
  def parse_pdf_task(file_path, **kwargs):
      result = partition_pdf(
          file=file_path,
          strategy='hi_res',
          infer_table_structure=True,
          **kwargs
      )
      # 可以把结果存到数据库或者缓存里，供后续查询
      return str(result)
  

  FastAPI里调用：

  from fastapi import FastAPI
  from celery_app import parse_pdf_task
  
  app = FastAPI()
  
  @app.post("/parse-pdf")
  async def trigger_parse_pdf(file_path: str):
      task = parse_pdf_task.delay(file_path)
      return {"task_id": task.id, "status": "submitted"}
  
  @app.get("/task-status/{task_id}")
  async def get_task_status(task_id: str):
      task = parse_pdf_task.AsyncResult(task_id)
      return {"task_id": task_id, "status": task.status, "result": task.result if task.successful() else None}
  

3. 调整FastAPI的运行参数 #

如果是本地开发或者单机器部署，给FastAPI多开几个Worker进程：

uvicorn main:app --workers 2 --host 0.0.0.0 --port 8000

这样即使某个Worker进程因为某种原因被阻塞（理论上不应该，但实际可能有意外），其他Worker还能处理请求。

总结 #

你当前的问题核心是子进程和主进程共享了磁盘/CPU资源，导致主进程无法及时处理请求。短期可以通过调整资源优先级、限制核心使用来缓解，长期最好用任务队列把PDF解析和FastAPI完全解耦，这才是生产环境的可靠方案。

内容来源于stack exchange