HTTPX 流式响应偶发 PoolTimeout:从连接未释放到生命周期闭环
Python 服务用 HTTPX 转发大文件、对象存储下载或上游 SSE 时,通常会启用流式响应,避免把整个响应体读入内存。上线后却可能出现一种很迷惑的故障:服务启动时一切正常,运行一段时间后请求开始批量报 httpx.PoolTimeout;重启进程能暂时恢复,单纯调大连接池只能延后复发。 这类问题往往不是上游连接慢
Category
当前分类下的文章。
Python 服务用 HTTPX 转发大文件、对象存储下载或上游 SSE 时,通常会启用流式响应,避免把整个响应体读入内存。上线后却可能出现一种很迷惑的故障:服务启动时一切正常,运行一段时间后请求开始批量报 httpx.PoolTimeout;重启进程能暂时恢复,单纯调大连接池只能延后复发。 这类问题往往不是上游连接慢
适用场景与现象 异步消费者、WebSocket 网关或定时任务服务收到 SIGTERM 后,健康检查已经失败,进程却迟迟不退出,最终被 Kubernetes 在宽限期结束时强制 SIGKILL。常见伴随现象是: 停机日志只出现“开始关闭”,没有“后台任务已结束”; 某个任务仍处于 PENDING,但业务请求已经停止进入
适用场景 一个常驻的 Python API、消费者或定时任务进程,刚启动时只占用几百 MB,运行数小时后内存持续上涨。请求结束后内存没有明显回落,重启可以暂时恢复,但过一段时间又出现同样问题。监控最终触发容器 OOMKilled,或节点开始频繁交换内存。 本文针对“对象仍被 Python 引用”的增长场景,演示如何用标
适用场景 FastAPI、Django ASGI 或自研 asyncio 服务会在同一线程交错处理多个请求。团队希望所有日志自动带上 request_id,却发现并发压测时标识偶尔串到另一个请求,或请求结束后启动的后台任务仍携带旧用户上下文。 本文用 Python 标准库复现并修复这个问题。重点不是某个 Web 框架的
适用场景 一个聚合接口同时读取用户资料与订单摘要,只有两项都成功才返回页面。某个依赖提前失败后,其他查询的结果已经没有用途,却仍占用连接和并发名额。本篇用纯标准库示例讨论这种“共同成功、共同结束”的请求边界。 示例需要 Python 3.11 或以上版本,本文在 Python 3.14 环境执行验证。演示使用内存事件替
适用场景 FastAPI 服务平时响应正常,但只要某个文件处理、旧版 SDK 调用或报表计算接口并发升高,健康检查、登录和其他无关接口也一起变慢。CPU、内存和数据库连接数未必异常,扩容 Uvicorn worker 后只能暂时缓解。 这类问题常见于 async def 路由中直接调用同步阻塞函数。本文给出一个可复现的
适用场景 生产环境执行 python manage.py migrate 后长时间没有结束,应用发布流水线被阻塞;或者迁移最终报出 Lock wait timeout exceeded、OperationalError。这类问题常见于 Django + MySQL/InnoDB:迁移本身很短,却在等待另一条业务 SQL
适用场景 Python 服务或批处理脚本通过 httpx 调用第三方 HTTP API。流量上来后,应用日志开始出现 httpx.PoolTimeout,但目标接口的监控显示延迟正常;重启服务后短暂恢复,随后问题又出现。常见于 FastAPI/Django 的异步任务、数据同步程序和并发爬取工具。 本文以 httpx.
适用场景 使用 Celery + Redis/RabbitMQ 承担异步任务。队列中仍有大量待执行任务,但监控显示少数 Worker 忙碌、其余 Worker 空闲;或者短任务被长任务“压住”,整体延迟持续升高。本文以默认的 prefork 并发池和 RabbitMQ 为例,Redis broker 的排查思路相同。
适用场景 这篇文章适用于使用 Python httpx 调用内部 HTTP 接口、第三方 API、网关或微服务时,线上偶发出现请求超时、任务堆积、接口吞吐下降的问题。常见场景包括: 定时任务批量调用接口; FastAPI、Django、Celery worker 中复用 httpx.Client 或 httpx.Asy