Azure PostgreSQL等待统计升高致性能降级 排查方案咨询

首先明确核心报错与等待事件的因果关联：报错could not receive data from client: An existing connection was forcibly closed by the remote host与排名第一的ClientRead等待直接相关，后续的IO: DataFileRead、LWLock: buffer_io等待大概率是连接异常、IO瓶颈触发的连锁反应，按以下优先级逐步排查即可：

1. 第一优先级：排查ClientRead等待与连接强制断开问题 #

ClientRead等待本质是PostgreSQL正在等待客户端发送请求数据，期间连接被客户端/中间层强制断开就会触发对应报错，排查点：

• 核对升级后数据库侧的连接超时参数：直接在库内执行show tcp_keepalives_idle;、show idle_in_transaction_session_timeout;查看配置值。Azure平台网关默认会断开空闲时长超过4分钟的TCP连接，如果tcp_keepalives_idle设置大于240秒，会出现连接被网关掐断但数据库侧不知情的情况，直接将该参数调整为120秒即可规避这类断连。
• 核对平台接入层配置：由于升级前未使用websockets技术，若新版本平台新增了websocket代理、七层负载均衡接入层，重点检查代理层的空闲连接超时阈值，确保代理超时值大于数据库侧TCP keepalive间隔，避免代理提前断开空闲连接。
• 核对业务侧连接逻辑：检查新版本业务代码的连接池配置、请求超时设置，若业务侧SQL执行超时阈值设置过短、异步请求未等待SQL返回就主动销毁数据库连接对象，也会触发大量强制断连。可通过查询pg_stat_activity视图，统计state为idle、idle in transaction的会话最长空闲时长，和业务侧超时配置做交叉比对。

2. 第二优先级：排查IO类等待的连锁性能问题 #

IO: DataFileRead是会话等待从磁盘读取数据页的等待事件，LWLock: buffer_io是多个会话同时等待同一个不在共享缓冲区的数据页时，等待IO锁释放产生的事件，两类等待通常成对出现，结合存在高频访问热表、使用PostgreSQL v11版本的场景，排查点：

• 检查热表缓存命中率：对高频访问的业务表，查询pg_statio_user_tables视图计算缓存命中率，公式为heap_blks_hit/(heap_blks_hit + heap_blks_read)，如果命中率低于99%，说明共享缓冲区配置不足，热数据无法常驻内存，会频繁触发磁盘读。可逐步调整shared_buffers参数到实例物理内存的25%，提升缓存容量。
• 检查存储IO配额占用：Azure PostgreSQL的IOPS上限与实例规格、存储容量绑定，直接在实例监控面板查看磁盘读IOPS、磁盘读延迟指标，如果IOPS打满、单块读延迟超过10ms，说明存储层存在瓶颈，可通过提升存储容量、升级实例规格提升IOPS配额。
• 检查慢SQL与索引有效性：捞取升级后新增的慢SQL日志，重点排查高频访问表上的SQL是否存在索引失效、缺失索引导致的全表扫描——全表扫描会大量占用共享缓冲区、触发大量随机磁盘IO，直接拉高buffer_io锁等待占比。针对高频点查场景，可在业务低峰期执行pg_prewarm将热表数据预加载到共享缓冲区，减少冷读带来的IO尖刺。

3. 快速验证步骤 #

按以下顺序操作可快速定位根因，无需依赖额外外部文档：

• 先调整TCP keepalive与事务空闲超时参数，观察连接强制断开的报错是否消失、ClientRead等待占比是否下降。
• 优化慢SQL、补全缺失索引，观察IO类等待指标的变化。
• 调整共享缓冲区大小、预加热表数据，验证buffer_io等待是否回落。
• 若以上操作后IO等待仍居高不下，核对存储IO指标是否触达配额上限，对应调整实例配置即可。

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