生产环境中排查hyperf连接池问题，核心是分层定位与指标交叉验证：先区分db/redis/grpc类型，再结合服务端状态、客户端配置、协程行为三方面比对，避免单点误判。
生产环境中排查 Hyperf 连接池连接数问题，核心是“分层定位 + 指标交叉验证”：先确认是哪类连接池（DB/Redis/gRPC）出问题，再结合服务端状态、客户端配置、协程行为三方面交叉比对，避免只看日志或只调参数。
一、快速识别问题类型和表现
不同连接池的异常现象差异明显，先对号入座：
-
MySQL/PostgreSQL：报
Too many clients（PG）或Too many connections（MySQL），SHOW PROCESSLIST显示大量sleep或idle连接；Prometheus 中hyperf_db_pool_used_connections长期 ≥90% -
Redis：协程卡在
$redis->get()几秒后抛WaitTimeoutException，swoole_get_local_socket_count()显示 ESTAB 连接数贴近max_connections；pipeline/multi 后未 exec 导致连接不释放 -
gRPC：服务端 TCP 连接数远超预期（如单 Worker 建立上百连接），
ss -tn | grep :port | wc -l持续增长；客户端无报错但延迟升高、CPU 占用异常
二、检查连接池关键配置是否匹配业务水位
配置不合理是高频根因，需对照实际 QPS 和平均耗时计算安全值：
-
max_connections：不能拍脑袋设。估算公式为
QPS × 平均执行耗时（秒）× 2~3 倍余量。例如 200 QPS × 0.15s = 30，建议设为 60–90；PostgreSQL 侧max_connections值必须 ≥ Hyperf 池上限的 1.4 倍 - wait_timeout：设太小（如 0.5）会频繁抛 WaitTimeoutException；设太大（如 10）掩盖真实瓶颈。推荐 2.0–5.0，高并发场景优先取下限
-
Swow 环境特别注意：必须删除旧
pool配置，改用min_connections/max_connections等 Swow 专用字段，且check_interval ≥ 3000ms
三、验证连接是否真正归还（排查泄漏）
连接借出不还，比连接数不够更危险——它会让池子“假性耗尽”：
-
Redis pipeline/multi：必须包裹在
try/finally中，确保exec()执行或显式调用discard()；Hyperf 3.1+ 推荐直接用withPipeline()封装方法 -
数据库事务：检查所有
beginTransaction()是否都有对应commit()或rollback()，异常分支不能遗漏 -
gRPC 客户端：禁止在业务逻辑中调用
conn.Close()；连接池自身不 Close，应在OnWorkerStop回调中统一关闭所有预创建连接
四、用系统级指标交叉验证
仅看 PHP 日志容易误判，要结合操作系统和数据库原生指标：
- 执行
ss -s | grep ESTAB或swoole_get_local_socket_count()，看实际 TCP 连接数是否持续贴近max_connections - PostgreSQL 执行
SELECT * FROM pg_stat_activity WHERE state = 'idle';，查长期 idle 的连接来源 - MySQL 查
SHOW STATUS LIKE 'Threads_connected';，对比 Hyperf 上报的hyperf_db_pool_used_connections，若前者远大于后者，说明有连接未进池或已泄漏 - 用
mysqld_exporter抓取mysql_global_status_innodb_row_lock_time_avg，若该值突增而hyperf_db_query_duration_ms正常，说明是锁竞争而非连接池问题
