FastAPI服务内存持续上涨，memory-profiler未显示GC回收问题

问题背景 #

部署的FastAPI服务初始内存约600MB，运行数天后内存攀升至5GB且无法回落。通过中间件结合memory-profiler观测发现：单次请求处理结束后内存无下降，连续调用时下一次请求的初始内存与上一次结束时一致，未如预期触发GC释放内存。（三次调用内存截图显示每次请求内存阶梯式上升，无回落）

内存未被释放的核心原因 #

• Python内存池机制：CPython的内存分配器会将释放的内存保留在进程内部的内存池中，供后续对象分配复用，不会立刻还给操作系统。这意味着即使GC回收了无用对象，进程的RSS（常驻内存）数值可能不会立刻下降，这是Python内存管理的正常行为，但不会导致长期的持续增长。
• 实际内存泄漏：如果内存长期攀升至5GB，必然存在对象引用泄漏：
  • 全局变量/类静态变量持续累积数据（比如未做清理的全局缓存、请求日志列表）；
  • 闭包、装饰器或依赖项意外持有对象引用，导致无法被GC回收；
  • 第三方库（如ORM客户端、机器学习模型、缓存工具）内部存在未释放的对象池或连接；
• memory-profiler的观测限制：该工具追踪的是Python层面的对象内存分配，但进程级内存包含了内存池未归还系统的部分，所以即使Python层面释放了对象，观测到的进程内存可能不会立刻回落。

现象是否正常？ #

单次请求后内存不回落不一定异常——可能是内存池预热后的缓存行为，若内存稳定在某一值不再增长，属于正常情况。但内存长期持续攀升至5GB且无回落是明确的异常，说明存在持续的内存泄漏，而非单纯的内存池缓存。

排查与解决建议 #

• 排查全局状态：检查代码中的全局变量、类静态属性，确认是否存在无限制添加数据的逻辑（如global_data.append(request_data)），添加定期清理机制。
• 精准定位泄漏点：使用tracemalloc追踪内存分配的具体代码位置：

  import tracemalloc
  from fastapi import FastAPI
  
  app = FastAPI()
  tracemalloc.start()
  
  @app.get("/")
  async def root():
      snapshot_before = tracemalloc.take_snapshot()
      # 你的业务逻辑
      snapshot_after = tracemalloc.take_snapshot()
      top_diff = snapshot_after.compare_to(snapshot_before, 'lineno')
      print("内存增长Top 5:")
      for stat in top_diff[:5]:
          print(stat)
      return {"message": "Hello World"}
  

• 验证GC效果：在请求结束后手动调用gc.collect()，若内存下降，说明自动GC触发时机滞后；若仍无变化，说明存在强引用无法被回收，需进一步排查引用链。
• 检查第三方依赖：确认使用的数据库客户端、模型库是否存在已知的内存泄漏问题，尝试升级依赖或调整配置（如限制连接池大小）。
• 部署模式调整：若使用Uvicorn多进程模式，检查是否单个子进程内存泄漏，可配置进程自动重启机制（如--max-requests）限制单个进程的生命周期。

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