Python 并发子任务失败后仍在运行：TaskGroup 取消与资源回收实践
## 适用场景 一个聚合接口同时读取用户资料与订单摘要，只有两项都成功才返回页面。某个依赖提前失败后，其他查询的结果已经没有用途，却仍占用连接和并发名额。本篇用纯标准库示例讨论这种“共同成功、共同结束”的请求边界。 示例需要 Python 3.11 或以上版本，本文在 Python 3.14 环境执行验证。演示使用
Tag
#排查
包含这个标签的文章。
PostgreSQL 连接池耗尽：从 idle in transaction 到事务边界治理
## 适用场景 应用运行一段时间后，新请求开始等待数据库连接，接口 P99 持续升高，最终出现连接池获取超时或 PostgreSQL `too many connections`。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后
FastAPI 接口并发升高后全站变慢：阻塞调用卡住事件循环的定位与治理
## 适用场景 FastAPI 服务平时响应正常，但只要某个文件处理、旧版 SDK 调用或报表计算接口并发升高，健康检查、登录和其他无关接口也一起变慢。CPU、内存和数据库连接数未必异常，扩容 Uvicorn worker 后只能暂时缓解。 这类问题常见于 `async def` 路由中直接调用同步阻塞函数。本文给
Nginx 大文件上传返回 413：从限制链路定位到安全放行的排查实践
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时，小文件正常，大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录，客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例，说明怎样确认
MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
Nginx 反向代理后客户端 IP 全变内网地址：从 realip 配置到防伪造的排查实践
## 适用场景 业务服务部署在负载均衡、CDN、Kubernetes Ingress 或四层代理之后。应用日志中的 `remote_addr` 全是代理的内网地址，限流、风控和审计都无法识别真实访问者；更危险的是，直接信任请求携带的 `X-Forwarded-For`，会让攻击者伪造来源 IP 绕过白名单。 本文以
Linux 时间漂移导致 JWT 校验失败与 TLS 握手异常：从证据采集到 chrony 治理
## 适用场景 适用于运行在 Linux 虚拟机、物理机或容器节点上的 Web 服务。业务表现为同一版本在部分机器上间歇出现登录失效、JWT `token is not active` / `token expired`、HTTPS 握手失败或调用云 API 返回签名过期；重试、重启应用有时短暂恢复，但问题会再次出现
DNS 记录已变更但业务仍访问旧地址：从缓存链路到灰度切换的排查实践
## 适用场景 线上服务切换负载均衡、迁移 API 网关或故障切流后，权威 DNS 已显示新 IP，但仍有一部分客户端持续访问旧地址。常见表现包括：请求间歇超时、少量用户仍命中已下线机房、发布后错误率在一个较长窗口内缓慢回落。 本文以 `api.example.com` 从 `203.0.113.10` 切换到 `
MySQL binlog 突增吃满磁盘：从定位大事务到安全清理的排查实践
## 适用场景 MySQL 主库所在分区持续增长，`/var/lib/mysql` 已接近 100%，业务开始出现写入失败、事务提交变慢，甚至因为磁盘写满而触发只读保护。检查目录后发现大量 `mysql-bin.000xxx` 文件，但不能直接删除：binlog 仍可能被复制从库、增量备份或审计流程使用。 本文适用
Kubernetes 滚动发布卡住：用 startupProbe 避免慢启动应用被 livenessProbe 反复误杀
## 适用场景 Java、Django、Node.js 等服务在 Kubernetes 中滚动发布后，新 Pod 长时间处于 `CrashLoopBackOff`，Deployment 一直无法完成；而在开发或低负载环境中启动正常。日志常只来得及打印数据库连接、缓存预热或迁移检查的前几行。 本文以“应用冷启动约 9