如何分析高负载下依赖PostgreSQL的Flask应用挂起问题

一、Gunicorn Worker超时的原因 #

当PostgreSQL触发statement_timeout时，如果数据库驱动（如psycopg2）或SQLAlchemy未正确捕获超时异常，会导致Gunicorn worker进程一直卡在等待数据库响应的状态。Gunicorn会监控worker的请求处理时长，一旦超过配置的timeout阈值就会杀死并重启worker。你把statement_timeout从30秒降到15秒，意味着worker会更快进入无响应状态，所以Gunicorn的超时回收触发得更早。

二、pg_stat_activity看不到运行中查询的可能原因 #

1. Pgbouncer连接模式影响：如果Pgbouncer使用transaction或statement连接模式，它会复用PostgreSQL连接——应用的查询执行完成后，连接会放回Pgbouncer的池里，而非立即断开。此时PostgreSQL的连接处于idle状态，查询pg_stat_activity自然看不到正在运行的应用查询。如果是session模式，每个应用连接对应一个专属的PostgreSQL连接，才能在pg_stat_activity里看到实时查询。
2. 查询执行周期短：压测时查询可能快速执行完毕，手动查询pg_stat_activity的时间点刚好错过，建议用连续采样命令实时监控：

   watch -n 1 "psql -U your_user -d your_db -c 'select pid, query, state from pg_stat_activity where state != ''idle'''"
   

3. 请求卡在Pgbouncer等待队列：应用请求还没发到PostgreSQL，就被卡在Pgbouncer的连接等待队列里，此时pg_stat_activity自然没有对应的运行查询。这种情况可以通过show clients;里的wait列（值为1表示正在等待）确认。

三、分步调试方案 #

1. 排查Pgbouncer配置与状态 #

先检查pgbouncer.ini的核心配置：

• pool_mode：确认当前使用的连接模式，判断是否是导致pg_stat_activity无数据的原因
• max_client_conn：最大客户端连接数，需大于等于Gunicorn进程数 × 每个进程的SQLAlchemy连接池大小（例如3个Gunicorn进程，每个池大小设为5，需至少15的max_client_conn）
• default_pool_size：每个数据库的连接池大小，需能支撑并发请求，同时不能超过PostgreSQL的max_connections

执行以下命令查看Pgbouncer实时状态：

• show pools;：查看各数据库的连接池情况，cl_waiting数值大于0说明有客户端在等待Pgbouncer分配连接
• show clients;：查看所有客户端连接，wait列值为1的就是处于等待状态的请求
• show stats;：查看请求量、等待次数、超时统计等指标，定位是否有连接池瓶颈

2. 调整Gunicorn与SQLAlchemy连接池 #

• Gunicorn worker数：建议设置为和服务器CPU核心数一致（例如4核CPU设4个worker），避免进程过多导致上下文切换开销过大，同时要和Pgbouncer的连接池容量匹配
• SQLAlchemy连接池：
  • 每个Gunicorn进程的pool_size不要过大（建议3-5），避免耗尽Pgbouncer的连接池
  • 设置pool_recycle参数（例如300秒），防止连接被PostgreSQL主动断开后变成无效连接
  • 合理配置max_overflow（临时溢出连接数），但要确保总连接数（进程数 × (pool_size + max_overflow)）不超过Pgbouncer的max_client_conn

3. 监控PostgreSQL真实负载 #

• 查看pg_stat_database：通过tup_fetched、tup_returned、xact_commit等指标，判断数据库是否在处理请求（即使pg_stat_activity看不到实时查询）
• 开启慢查询日志：在postgresql.conf中设置log_min_duration_statement = 0（记录所有查询）或100（记录耗时超过100ms的查询），事后分析哪些查询性能差
• 检查锁等待：执行select * from pg_locks where not granted;，如果存在未授权的锁，说明有查询被锁阻塞，这也是导致请求无响应的常见原因

4. 验证连接链路 #

• 绕过Pgbouncer，直接让应用连接PostgreSQL，重新压测：如果问题消失，说明根源在Pgbouncer的配置或连接池；如果问题依然存在，说明问题出在PostgreSQL本身或查询性能
• 单独测试查询性能：用psql执行测试页面的两个查询，查看单查询耗时，如果单查询就很慢，优先优化查询语句（比如加索引、重构逻辑）

5. 修复Gunicorn Worker超时问题 #

• 适当调大Gunicorn的timeout参数：如果查询确实需要较长时间完成，可以临时调大，但这只是治标，核心还是要解决数据库或连接池的瓶颈
• 确保超时异常被正确捕获：在SQLAlchemy连接配置中明确设置connect_timeout，同时在PostgreSQL连接级别设置statement_timeout，保证超时后能抛出异常，避免worker进程卡住

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