跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

LWLock 等待

PostgreSQL 内部共享内存数据结构上的竞争。

LWLock 表示后端没能立即取得保护内部共享内存结构的轻量级锁。它不是 SQL 行锁或表锁,pg_locks 通常也无法指出它的持有者。

值班规则重复采样 → 锁定一个热点 tranche → 与负载关联

怎样阅读这一类

单张快照里的 LWLock 通常只是调度噪声。只有同一个名称在连续样本中反复出现,并且受影响前台会话的延迟同步上升时,才把它当成竞争。

  • 正常: 生成 WAL、获取快照、查找缓冲区、清理或检查点期间短暂出现。
  • 关注: 连续三张、间隔 1 秒的快照里,同一事件至少占活动前台后端的 10%。
  • 紧急: 至少 25% 的活动前台后端堆在同一事件上,等待持续超过 5 秒,或吞吐同时断崖式下降。

这些百分比是现场分级阈值,不是 PostgreSQL 的保证值。必须与本集群基线比较,并排除本来就应在主循环中等待的后台进程。

值得先认出的十个事件

事件 受保护资源 常见现场
BufferContent 单个共享缓冲区的内容 大量会话访问同一热点页
BufferMapping 缓冲区映射表分区 工作集抖动或大规模并发扫描
LockManager 重量级锁管理器状态 锁数量爆炸、DDL 或锁风暴
ProcArray 共享进程/事务数组 获取快照与事务 ID 压力
WALBufMapping WAL 缓冲区页面映射 写入压力下 WAL buffer 快速换页
WALInsert WAL 插入状态 大量写会话在插入 WAL 时串行化
WALWrite WAL 缓冲区写协调 WAL 写入或刷盘路径跟不上
XactSLRU 事务状态 SLRU pg_xact 缓存抖动或检查很老的可见性
MultiXactMemberSLRU Multixact member SLRU 大量行锁与 multixact 抖动
SyncRep 同步复制等待队列 提交确认与 sender 状态发生竞争

常见误读

  1. “LWLock 说明锁泄漏了。” 不是。它是短暂的内部临界区;持续、重复出现才是信号。
  2. “页面显示的查询就是持有者。” pg_stat_activity.query 属于等待者;持有者可能是走另一条源码路径的后端。
  3. “多加 CPU 就能解决。” 更多并发反而可能加剧共享内存热点。先确认受保护资源与负载形状。
  4. pg_locks 能找出阻塞者。” 它覆盖重量级锁与谓词锁,不覆盖一般 LWLock 所有权。

页面级热点先看 BufferContent,写入密集集群先看 WALInsert

1 - LWLock: AddinShmemInit

等待管理扩展在共享内存中的空间分配。
PostgreSQL 等待事件档案
类别LWLock 事件AddinShmemInit 版本PG 13-18 证据3 个源码位置

官方描述译文

等待管理扩展在共享内存中的空间分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:328。探针覆盖的操作是:等待管理扩展在共享内存中的空间分配。LWLockAcquire 无法立即取得显示为 AddinShmemInit 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AddinShmemInit 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AddinShmemInit'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AddinShmemInit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

2 - LWLock: AioUringCompletion

等待另一个进程通过 io_uring 完成 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件AioUringCompletion 版本PG 18 证据3 个源码位置

官方描述译文

等待另一个进程通过 io_uring 完成 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:180。探针覆盖的操作是:等待另一个进程通过 io_uring 完成 I/O。LWLockAcquire 无法立即取得显示为 AioUringCompletion 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AioUringCompletion 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AioUringCompletion'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AioUringCompletion'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

3 - LWLock: AioWorkerSubmissionQueue

等待访问 AIO worker 提交队列。
PostgreSQL 等待事件档案
类别LWLock 事件AioWorkerSubmissionQueue 版本PG 18 证据3 个源码位置

官方描述译文

等待访问 AIO worker 提交队列。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/aio/method_worker.c:253。探针覆盖的操作是:等待访问 AIO worker 提交队列。LWLockAcquire 无法立即取得显示为 AioWorkerSubmissionQueue 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AioWorkerSubmissionQueue 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AioWorkerSubmissionQueue'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AioWorkerSubmissionQueue'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

4 - LWLock: AutoFile

等待更新 postgresql.auto.conf 文件。
PostgreSQL 等待事件档案
类别LWLock 事件AutoFile 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新 postgresql.auto.conf 文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:340。探针覆盖的操作是:等待更新 postgresql.auto.conf 文件。LWLockAcquire 无法立即取得显示为 AutoFile 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AutoFile 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AutoFile'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AutoFile'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

5 - LWLock: Autovacuum

等待读取或更新 autovacuum worker 的当前状态。
PostgreSQL 等待事件档案
类别LWLock 事件Autovacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 autovacuum worker 的当前状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/autovacuum.c:611。探针覆盖的操作是:等待读取或更新 autovacuum worker 的当前状态。LWLockAcquire 无法立即取得显示为 Autovacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/Autovacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'Autovacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'Autovacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

6 - LWLock: AutovacuumSchedule

等待确认被选中进行 autovacuum 的表仍需要 vacuum。
PostgreSQL 等待事件档案
类别LWLock 事件AutovacuumSchedule 版本PG 13-18 证据3 个源码位置

官方描述译文

等待确认被选中进行 autovacuum 的表仍需要 vacuum。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/autovacuum.c:2337。探针覆盖的操作是:等待确认被选中进行 autovacuum 的表仍需要 vacuum。LWLockAcquire 无法立即取得显示为 AutovacuumSchedule 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AutovacuumSchedule 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AutovacuumSchedule'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AutovacuumSchedule'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

7 - LWLock: BackgroundWorker

等待读取或更新后台 worker 的状态。
PostgreSQL 等待事件档案
类别LWLock 事件BackgroundWorker 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新后台 worker 的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/bgworker.c:1070。探针覆盖的操作是:等待读取或更新后台 worker 的状态。LWLockAcquire 无法立即取得显示为 BackgroundWorker 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/BackgroundWorker 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BackgroundWorker'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BackgroundWorker'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

8 - LWLock: BtreeVacuum

等待读取或更新 B-tree 索引中与 vacuum 相关的信息。
PostgreSQL 等待事件档案
类别LWLock 事件BtreeVacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 B-tree 索引中与 vacuum 相关的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/nbtree/nbtutils.c:3519。探针覆盖的操作是:等待读取或更新 B-tree 索引中与 vacuum 相关的信息。LWLockAcquire 无法立即取得显示为 BtreeVacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/BtreeVacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BtreeVacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BtreeVacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

9 - LWLock: BufferContent

等待访问内存中的数据页。
PostgreSQL 等待事件档案
类别LWLock 事件BufferContent 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问内存中的数据页。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

后端已经找到所需的共享缓冲区,但尚未取得该 buffer descriptor 的 content lock。堆表与索引代码在读取或修改内存页前都会取得此锁,因此大量工作进程访问同一页面时会在这里串行化。

正常还是麻烦?

  • 正常: 并发读写共享页面时,零星而短暂的样本很常见。
  • 需要调查: 大量前台会话连续命中时,通常指向热点堆表/索引页、向右增长的索引,或与业务同时访问相同块的维护任务。

诊断 SQL

正在等待 LWLock/BufferContent 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BufferContent'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BufferContent'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 找出等待会话共同访问的关系与语句。
  2. 用页面与索引证据确认热点,不能只凭等待名称下结论。
  3. 先分散热点键、批量写入或错峰维护,再考虑容量调整。

源码证据

典型事故模式

单调递增键让并发 B-tree 插入集中到最右叶子页,BufferContent 与插入延迟同步上升。

10 - LWLock: BufferMapping

等待将数据块关联到 buffer pool 中的 buffer。
PostgreSQL 等待事件档案
类别LWLock 事件BufferMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将数据块关联到 buffer pool 中的 buffer。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

缓冲区管理器把 relation/fork/block 标签哈希到由 BufferMappingLock 保护的分区。查找、插入、淘汰和重新分配标签都会短暂取得该分区锁;大规模并发未命中或缓冲区抖动会增加碰撞。

正常还是麻烦?

  • 正常: 页面进入或离开共享缓冲区时,短暂等待属于正常现象。
  • 需要调查: 持续出现通常意味着工作集反复冲刷 shared buffers、大量并行扫描,或访问集中映射到少数分区。

诊断 SQL

正在等待 LWLock/BufferMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BufferMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BufferMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按数据库与语句关联缓冲命中率和读取量。
  2. 检查是否出现新扫描、缓存过小或并发突增。
  3. 先降低并发扫描扇出或修正访问路径,再决定是否扩大 shared_buffers。

源码证据

典型事故模式

执行计划退化引发大量并发大扫描,缓冲映射分区变热,同时有用页面被挤出缓存。

11 - LWLock: Checkpoint

等待开始执行检查点。
PostgreSQL 等待事件档案
类别LWLock 事件Checkpoint 版本PG 13 证据3 个源码位置

官方描述译文

等待开始执行检查点。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:765,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/xlog.c:8957。探针覆盖的操作是:等待开始执行检查点。LWLockAcquire 无法立即取得显示为 Checkpoint 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/Checkpoint 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'Checkpoint'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'Checkpoint'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

12 - LWLock: CheckpointerComm

等待管理 fsync 请求。
PostgreSQL 等待事件档案
类别LWLock 事件CheckpointerComm 版本PG 13-18 证据3 个源码位置

官方描述译文

等待管理 fsync 请求。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/checkpointer.c:1164。探针覆盖的操作是:等待管理 fsync 请求。LWLockAcquire 无法立即取得显示为 CheckpointerComm 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CheckpointerComm 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CheckpointerComm'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CheckpointerComm'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

13 - LWLock: CommitTs

等待读取或更新事务提交时间戳的最近设定值。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTs 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新事务提交时间戳的最近设定值。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/commit_ts.c:206。探针覆盖的操作是:等待读取或更新事务提交时间戳的最近设定值。LWLockAcquire 无法立即取得显示为 CommitTs 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTs 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTs'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTs'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

14 - LWLock: CommitTsBuffer

等待事务提交时间戳 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTsBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待事务提交时间戳 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:141。探针覆盖的操作是:等待事务提交时间戳 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 CommitTsBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTsBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTsBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTsBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

15 - LWLock: CommitTsSLRU

等待访问事务提交时间戳 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTsSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问事务提交时间戳 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:172。探针覆盖的操作是:等待访问事务提交时间戳 SLRU 缓存。LWLockAcquire 无法立即取得显示为 CommitTsSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTsSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTsSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTsSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

16 - LWLock: ControlFile

等待读取或更新 pg_control 文件,或创建新的 WAL 文件。
PostgreSQL 等待事件档案
类别LWLock 事件ControlFile 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_control 文件,或创建新的 WAL 文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/xlog.c:2723。探针覆盖的操作是:等待读取或更新 pg_control 文件,或创建新的 WAL 文件。LWLockAcquire 无法立即取得显示为 ControlFile 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ControlFile 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ControlFile'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ControlFile'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

17 - LWLock: DSMRegistry

等待读取或更新动态共享内存注册表。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistry 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新动态共享内存注册表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/dsm_registry.c:98。探针覆盖的操作是:等待读取或更新动态共享内存注册表。LWLockAcquire 无法立即取得显示为 DSMRegistry 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistry 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistry'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistry'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

18 - LWLock: DSMRegistryDSA

等待访问动态共享内存注册表的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistryDSA 版本PG 17-18 证据3 个源码位置

官方描述译文

等待访问动态共享内存注册表的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:170。探针覆盖的操作是:等待访问动态共享内存注册表的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 DSMRegistryDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistryDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistryDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistryDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

19 - LWLock: DSMRegistryHash

等待访问动态共享内存注册表的共享哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistryHash 版本PG 17-18 证据3 个源码位置

官方描述译文

等待访问动态共享内存注册表的共享哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:171。探针覆盖的操作是:等待访问动态共享内存注册表的共享哈希表。LWLockAcquire 无法立即取得显示为 DSMRegistryHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistryHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistryHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistryHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

20 - LWLock: DynamicSharedMemoryControl

等待读取或更新动态共享内存分配信息。
PostgreSQL 等待事件档案
类别LWLock 事件DynamicSharedMemoryControl 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新动态共享内存分配信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/dsm.c:549。探针覆盖的操作是:等待读取或更新动态共享内存分配信息。LWLockAcquire 无法立即取得显示为 DynamicSharedMemoryControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DynamicSharedMemoryControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DynamicSharedMemoryControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DynamicSharedMemoryControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

21 - LWLock: InjectionPoint

等待读取或更新与注入点相关的信息。
PostgreSQL 等待事件档案
类别LWLock 事件InjectionPoint 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新与注入点相关的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:353。探针覆盖的操作是:等待读取或更新与注入点相关的信息。LWLockAcquire 无法立即取得显示为 InjectionPoint 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/InjectionPoint 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'InjectionPoint'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'InjectionPoint'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

22 - LWLock: LockFastPath

等待读取或更新进程的快速路径锁信息。
PostgreSQL 等待事件档案
类别LWLock 事件LockFastPath 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新进程的快速路径锁信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:151。探针覆盖的操作是:等待读取或更新进程的快速路径锁信息。LWLockAcquire 无法立即取得显示为 LockFastPath 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LockFastPath 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LockFastPath'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LockFastPath'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

23 - LWLock: LockManager

等待读取或更新“重量级”锁的信息。
PostgreSQL 等待事件档案
类别LWLock 事件LockManager 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新“重量级”锁的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

重量级锁的账本存放在由 LockHashPartitionLock 分区保护的共享哈希表中。获取、授予、释放或检查大量重量级锁时,即使不存在 SQL 层锁冲突,也可能在分区锁上竞争。

正常还是麻烦?

  • 正常: 普通关系锁与事务锁流量会带来小规模突发。
  • 需要调查: 持续占比通常来自锁扇出:超大事务、大量分区、频繁 DDL,或成千上万的排队锁请求。

诊断 SQL

正在等待 LWLock/LockManager 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LockManager'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LockManager'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按 PID 统计 pg_locks 行数并检查阻塞树。
  2. 定位一次触碰大量关系或分区的语句。
  3. 缩短事务并降低锁扇出;只有真实容量报错时才提高 max_locks_per_transaction。

源码证据

典型事故模式

发布过程对数千分区执行 DDL,同时业务会话获取关系锁;在明显阻塞者出现前,内部锁表已经发生竞争。

24 - LWLock: LogicalRepLauncherDSA

等待访问逻辑复制 launcher 的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepLauncherDSA 版本PG 16-18 证据3 个源码位置

官方描述译文

等待访问逻辑复制 launcher 的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:168。探针覆盖的操作是:等待访问逻辑复制 launcher 的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 LogicalRepLauncherDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepLauncherDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepLauncherDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepLauncherDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

25 - LWLock: LogicalRepLauncherHash

等待访问逻辑复制 launcher 的共享哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepLauncherHash 版本PG 16-18 证据3 个源码位置

官方描述译文

等待访问逻辑复制 launcher 的共享哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:169。探针覆盖的操作是:等待访问逻辑复制 launcher 的共享哈希表。LWLockAcquire 无法立即取得显示为 LogicalRepLauncherHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepLauncherHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepLauncherHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepLauncherHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

26 - LWLock: LogicalRepWorker

等待读取或更新逻辑复制 worker 的状态。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepWorker 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新逻辑复制 worker 的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/launcher.c:189。探针覆盖的操作是:等待读取或更新逻辑复制 worker 的状态。LWLockAcquire 无法立即取得显示为 LogicalRepWorker 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepWorker 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepWorker'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepWorker'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

27 - LWLock: MultiXactGen

等待读取或更新共享 multixact 状态。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新共享 multixact 状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/multixact.c:738。探针覆盖的操作是:等待读取或更新共享 multixact 状态。LWLockAcquire 无法立即取得显示为 MultiXactGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

28 - LWLock: MultiXactMemberBuffer

等待 multixact member SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactMemberBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 multixact member SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:144。探针覆盖的操作是:等待 multixact member SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 MultiXactMemberBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactMemberBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactMemberBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactMemberBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

29 - LWLock: MultiXactMemberSLRU

等待访问 multixact member SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactMemberSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 multixact member SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

此锁保护 pg_multixact/members 的 SLRU 缓存;这里保存共享行锁使用的 multitransaction ID 成员事务。并发行锁创建与旧成员查询会在这里相遇。

正常还是麻烦?

  • 正常: 使用 SELECT FOR SHARE/KEY SHARE,或因外键检查创建 multixact 的负载中会短暂出现。
  • 需要调查: 持续竞争指向大量共享行锁、multixact 抖动、冻结落后,或 pg_multixact 存储缓慢。

诊断 SQL

正在等待 LWLock/MultiXactMemberSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactMemberSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactMemberSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 找出制造大量共享行锁的语句与表。
  2. 检查 multixact 年龄与 autovacuum 进度。
  3. 降低锁扇出并解除 multixact 冻结阻塞;若同时出现 buffer 等待,再查 member SLRU I/O。

源码证据

典型事故模式

高扇出的外键负载锁住大量父表行,同时长事务推迟 multixact 清理,最终引发 member 缓存竞争。

30 - LWLock: MultiXactOffsetBuffer

等待 multixact offset SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactOffsetBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 multixact offset SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:143。探针覆盖的操作是:等待 multixact offset SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 MultiXactOffsetBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactOffsetBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactOffsetBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactOffsetBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

31 - LWLock: MultiXactOffsetSLRU

等待访问 multixact offset SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactOffsetSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 multixact offset SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:173。探针覆盖的操作是:等待访问 multixact offset SLRU 缓存。LWLockAcquire 无法立即取得显示为 MultiXactOffsetSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactOffsetSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactOffsetSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactOffsetSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

32 - LWLock: MultiXactTruncation

等待读取或截断 multixact 信息。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactTruncation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或截断 multixact 信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/multixact.c:2901。探针覆盖的操作是:等待读取或截断 multixact 信息。LWLockAcquire 无法立即取得显示为 MultiXactTruncation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactTruncation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactTruncation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactTruncation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

33 - LWLock: NotifyBuffer

等待 NOTIFY 消息 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 NOTIFY 消息 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:145。探针覆盖的操作是:等待 NOTIFY 消息 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 NotifyBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

34 - LWLock: NotifyQueue

等待读取或更新 NOTIFY 消息。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyQueue 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 NOTIFY 消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/async.c:940。探针覆盖的操作是:等待读取或更新 NOTIFY 消息。LWLockAcquire 无法立即取得显示为 NotifyQueue 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyQueue 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyQueue'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyQueue'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

35 - LWLock: NotifyQueueTail

等待更新 NOTIFY 消息的存储上限。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyQueueTail 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新 NOTIFY 消息的存储上限。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/async.c:2126。探针覆盖的操作是:等待更新 NOTIFY 消息的存储上限。LWLockAcquire 无法立即取得显示为 NotifyQueueTail 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyQueueTail 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyQueueTail'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyQueueTail'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

36 - LWLock: NotifySLRU

等待访问 NOTIFY 消息 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件NotifySLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 NOTIFY 消息 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:175。探针覆盖的操作是:等待访问 NOTIFY 消息 SLRU 缓存。LWLockAcquire 无法立即取得显示为 NotifySLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifySLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifySLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifySLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

37 - LWLock: OidGen

等待分配新的 OID。
PostgreSQL 等待事件档案
类别LWLock 事件OidGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配新的 OID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:563。探针覆盖的操作是:等待分配新的 OID。LWLockAcquire 无法立即取得显示为 OidGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/OidGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'OidGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'OidGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

38 - LWLock: OldSnapshotTimeMap

等待读取或更新旧快照控制信息。
PostgreSQL 等待事件档案
类别LWLock 事件OldSnapshotTimeMap 版本PG 13-16 证据2 个源码位置

官方描述译文

等待读取或更新旧快照控制信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:750,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/time/snapmgr.c:1758。探针覆盖的操作是:等待读取或更新旧快照控制信息。LWLockAcquire 无法立即取得显示为 OldSnapshotTimeMap 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/OldSnapshotTimeMap 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'OldSnapshotTimeMap'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'OldSnapshotTimeMap'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

39 - LWLock: ParallelAppend

执行 Parallel Append 计划期间,等待选择下一个子计划。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelAppend 版本PG 13-18 证据3 个源码位置

官方描述译文

执行 Parallel Append 计划期间,等待选择下一个子计划。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/executor/nodeAppend.c:69。探针覆盖的操作是:执行 Parallel Append 计划期间,等待选择下一个子计划。LWLockAcquire 无法立即取得显示为 ParallelAppend 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelAppend 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelAppend'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelAppend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

40 - LWLock: ParallelBtreeScan

执行 Parallel B-tree Scan 计划期间,等待同步 worker。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelBtreeScan 版本PG 18 证据3 个源码位置

官方描述译文

执行 Parallel B-tree Scan 计划期间,等待同步 worker。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:156。探针覆盖的操作是:执行 Parallel B-tree Scan 计划期间,等待同步 worker。LWLockAcquire 无法立即取得显示为 ParallelBtreeScan 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelBtreeScan 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelBtreeScan'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelBtreeScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

41 - LWLock: ParallelHashJoin

执行 Parallel Hash Join 计划期间,等待同步 worker。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelHashJoin 版本PG 13-18 证据3 个源码位置

官方描述译文

执行 Parallel Hash Join 计划期间,等待同步 worker。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/executor/nodeHash.c:71。探针覆盖的操作是:执行 Parallel Hash Join 计划期间,等待同步 worker。LWLockAcquire 无法立即取得显示为 ParallelHashJoin 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelHashJoin 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelHashJoin'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelHashJoin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

42 - LWLock: ParallelQueryDSA

等待并行查询的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelQueryDSA 版本PG 13-18 证据3 个源码位置

官方描述译文

等待并行查询的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:157。探针覆盖的操作是:等待并行查询的动态共享内存分配。LWLockAcquire 无法立即取得显示为 ParallelQueryDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelQueryDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelQueryDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelQueryDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

43 - LWLock: ParallelVacuumDSA

等待并行 vacuum 的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelVacuumDSA 版本PG 17-18 证据3 个源码位置

官方描述译文

等待并行 vacuum 的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:179。探针覆盖的操作是:等待并行 vacuum 的动态共享内存分配。LWLockAcquire 无法立即取得显示为 ParallelVacuumDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelVacuumDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelVacuumDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelVacuumDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

44 - LWLock: PerSessionDSA

等待并行查询的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionDSA 版本PG 13-18 证据3 个源码位置

官方描述译文

等待并行查询的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:158。探针覆盖的操作是:等待并行查询的动态共享内存分配。LWLockAcquire 无法立即取得显示为 PerSessionDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

45 - LWLock: PerSessionRecordType

等待访问并行查询的复合类型信息。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionRecordType 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问并行查询的复合类型信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:159。探针覆盖的操作是:等待访问并行查询的复合类型信息。LWLockAcquire 无法立即取得显示为 PerSessionRecordType 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionRecordType 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionRecordType'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionRecordType'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

46 - LWLock: PerSessionRecordTypmod

等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionRecordTypmod 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:160。探针覆盖的操作是:等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。LWLockAcquire 无法立即取得显示为 PerSessionRecordTypmod 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionRecordTypmod 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionRecordTypmod'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionRecordTypmod'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

47 - LWLock: PerXactPredicateList

并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。
PostgreSQL 等待事件档案
类别LWLock 事件PerXactPredicateList 版本PG 13-18 证据3 个源码位置

官方描述译文

并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:164。探针覆盖的操作是:并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。LWLockAcquire 无法立即取得显示为 PerXactPredicateList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerXactPredicateList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerXactPredicateList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerXactPredicateList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

48 - LWLock: PgStatsDSA

等待访问统计信息的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsDSA 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问统计信息的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:165。探针覆盖的操作是:等待访问统计信息的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 PgStatsDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

49 - LWLock: PgStatsData

等待访问共享内存中的统计数据。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsData 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问共享内存中的统计数据。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:167。探针覆盖的操作是:等待访问共享内存中的统计数据。LWLockAcquire 无法立即取得显示为 PgStatsData 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsData 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsData'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

50 - LWLock: PgStatsHash

等待访问统计信息的共享内存哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsHash 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问统计信息的共享内存哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:166。探针覆盖的操作是:等待访问统计信息的共享内存哈希表。LWLockAcquire 无法立即取得显示为 PgStatsHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

51 - LWLock: PredicateLockManager

等待访问可串行化事务使用的谓词锁信息。
PostgreSQL 等待事件档案
类别LWLock 事件PredicateLockManager 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务使用的谓词锁信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:154。探针覆盖的操作是:等待访问可串行化事务使用的谓词锁信息。LWLockAcquire 无法立即取得显示为 PredicateLockManager 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PredicateLockManager 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PredicateLockManager'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PredicateLockManager'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

52 - LWLock: ProcArray

等待访问共享的进程级数据结构(通常用于获取快照或报告会话的事务 ID)。
PostgreSQL 等待事件档案
类别LWLock 事件ProcArray 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问共享的进程级数据结构(通常用于获取快照或报告会话的事务 ID)。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

ProcArrayLock 保护用于快照、事务可见性与事务结束处理的共享 PGPROC/PGXACT 数组。获取快照以及更新进程事务状态都必须短暂经过它协调。

正常还是麻烦?

  • 正常: 大量事务开始与结束的繁忙 OLTP 系统中,短暂等待属于预期。
  • 需要调查: 持续竞争可能伴随极高连接数、大量快照、长事务,或事务集中结束。

诊断 SQL

正在等待 LWLock/ProcArray 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ProcArray'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ProcArray'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 测量活动后端与事务年龄,不要只看总连接数。
  2. 找出让可见性边界停滞的长事务与 idle in transaction 会话。
  3. 使用连接池、缩短事务,并避免大量微事务同步突发。

源码证据

典型事故模式

应用重连风暴制造数千个短事务,同时报表查询持有旧快照,放大了 ProcArray 流量。

53 - LWLock: RelCacheInit

等待读取或更新 pg_internal.init relation cache 初始化文件。
PostgreSQL 等待事件档案
类别LWLock 事件RelCacheInit 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_internal.init relation cache 初始化文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:323。探针覆盖的操作是:等待读取或更新 pg_internal.init relation cache 初始化文件。LWLockAcquire 无法立即取得显示为 RelCacheInit 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/RelCacheInit 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'RelCacheInit'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'RelCacheInit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

54 - LWLock: RelationMapping

等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。
PostgreSQL 等待事件档案
类别LWLock 事件RelationMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:332。探针覆盖的操作是:等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。LWLockAcquire 无法立即取得显示为 RelationMapping 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/RelationMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'RelationMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'RelationMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

55 - LWLock: ReplicationOrigin

等待创建、删除或使用复制源。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationOrigin 版本PG 13-18 证据3 个源码位置

官方描述译文

等待创建、删除或使用复制源。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/origin.c:377。探针覆盖的操作是:等待创建、删除或使用复制源。LWLockAcquire 无法立即取得显示为 ReplicationOrigin 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationOrigin 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationOrigin'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationOrigin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

56 - LWLock: ReplicationOriginState

等待读取或更新一个复制源的进度。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationOriginState 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新一个复制源的进度。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/origin.c:557。探针覆盖的操作是:等待读取或更新一个复制源的进度。LWLockAcquire 无法立即取得显示为 ReplicationOriginState 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationOriginState 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationOriginState'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationOriginState'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

57 - LWLock: ReplicationSlotAllocation

等待分配或释放复制槽。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotAllocation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配或释放复制槽。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/slotsync.c:543。探针覆盖的操作是:等待分配或释放复制槽。LWLockAcquire 无法立即取得显示为 ReplicationSlotAllocation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotAllocation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotAllocation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotAllocation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

58 - LWLock: ReplicationSlotControl

等待读取或更新复制槽状态。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotControl 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新复制槽状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/logical.c:492。探针覆盖的操作是:等待读取或更新复制槽状态。LWLockAcquire 无法立即取得显示为 ReplicationSlotControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

59 - LWLock: ReplicationSlotIO

等待复制槽上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotIO 版本PG 13-18 证据3 个源码位置

官方描述译文

等待复制槽上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:150。探针覆盖的操作是:等待复制槽上的 I/O。LWLockAcquire 无法立即取得显示为 ReplicationSlotIO 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotIO 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotIO'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotIO'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

60 - LWLock: SInvalRead

等待从共享系统目录失效队列中取出消息。
PostgreSQL 等待事件档案
类别LWLock 事件SInvalRead 版本PG 13-18 证据3 个源码位置

官方描述译文

等待从共享系统目录失效队列中取出消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/sinvaladt.c:497。探针覆盖的操作是:等待从共享系统目录失效队列中取出消息。LWLockAcquire 无法立即取得显示为 SInvalRead 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SInvalRead 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SInvalRead'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SInvalRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

61 - LWLock: SInvalWrite

等待向共享系统目录失效队列中添加消息。
PostgreSQL 等待事件档案
类别LWLock 事件SInvalWrite 版本PG 13-18 证据3 个源码位置

官方描述译文

等待向共享系统目录失效队列中添加消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/sinvaladt.c:290。探针覆盖的操作是:等待向共享系统目录失效队列中添加消息。LWLockAcquire 无法立即取得显示为 SInvalWrite 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SInvalWrite 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SInvalWrite'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SInvalWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

62 - LWLock: SerialBuffer

等待可串行化事务冲突 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件SerialBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待可串行化事务冲突 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:146。探针覆盖的操作是:等待可串行化事务冲突 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 SerialBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

63 - LWLock: SerialControl

等待读取或更新共享的 pg_serial 状态。
PostgreSQL 等待事件档案
类别LWLock 事件SerialControl 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新共享的 pg_serial 状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:835。探针覆盖的操作是:等待读取或更新共享的 pg_serial 状态。LWLockAcquire 无法立即取得显示为 SerialControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

64 - LWLock: SerialSLRU

等待访问可串行化事务冲突 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件SerialSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务冲突 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:176。探针覆盖的操作是:等待访问可串行化事务冲突 SLRU 缓存。LWLockAcquire 无法立即取得显示为 SerialSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

65 - LWLock: SerializableFinishedList

等待访问已结束的可串行化事务列表。
PostgreSQL 等待事件档案
类别LWLock 事件SerializableFinishedList 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问已结束的可串行化事务列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:1507。探针覆盖的操作是:等待访问已结束的可串行化事务列表。LWLockAcquire 无法立即取得显示为 SerializableFinishedList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializableFinishedList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializableFinishedList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializableFinishedList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

66 - LWLock: SerializablePredicateList

等待访问可串行化事务所持有的谓词锁列表。
PostgreSQL 等待事件档案
类别LWLock 事件SerializablePredicateList 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务所持有的谓词锁列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:2220。探针覆盖的操作是:等待访问可串行化事务所持有的谓词锁列表。LWLockAcquire 无法立即取得显示为 SerializablePredicateList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializablePredicateList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializablePredicateList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializablePredicateList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

67 - LWLock: SerializableXactHash

等待读取或更新可串行化事务的信息。
PostgreSQL 等待事件档案
类别LWLock 事件SerializableXactHash 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新可串行化事务的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:1462。探针覆盖的操作是:等待读取或更新可串行化事务的信息。LWLockAcquire 无法立即取得显示为 SerializableXactHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializableXactHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializableXactHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializableXactHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

68 - LWLock: SharedTidBitmap

并行 bitmap index scan 期间,等待访问共享 TID bitmap。
PostgreSQL 等待事件档案
类别LWLock 事件SharedTidBitmap 版本PG 13-18 证据3 个源码位置

官方描述译文

并行 bitmap index scan 期间,等待访问共享 TID bitmap。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:162。探针覆盖的操作是:并行 bitmap index scan 期间,等待访问共享 TID bitmap。LWLockAcquire 无法立即取得显示为 SharedTidBitmap 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SharedTidBitmap 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SharedTidBitmap'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SharedTidBitmap'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

69 - LWLock: SharedTupleStore

并行查询期间,等待访问共享 tuple store。
PostgreSQL 等待事件档案
类别LWLock 事件SharedTupleStore 版本PG 13-18 证据3 个源码位置

官方描述译文

并行查询期间,等待访问共享 tuple store。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:161。探针覆盖的操作是:并行查询期间,等待访问共享 tuple store。LWLockAcquire 无法立即取得显示为 SharedTupleStore 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SharedTupleStore 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SharedTupleStore'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SharedTupleStore'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

70 - LWLock: ShmemIndex

等待在共享内存中查找或分配空间。
PostgreSQL 等待事件档案
类别LWLock 事件ShmemIndex 版本PG 13-18 证据3 个源码位置

官方描述译文

等待在共享内存中查找或分配空间。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/shmem.c:392。探针覆盖的操作是:等待在共享内存中查找或分配空间。LWLockAcquire 无法立即取得显示为 ShmemIndex 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ShmemIndex 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ShmemIndex'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ShmemIndex'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

71 - LWLock: SubtransBuffer

等待子事务 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件SubtransBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待子事务 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:142。探针覆盖的操作是:等待子事务 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 SubtransBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SubtransBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SubtransBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SubtransBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

72 - LWLock: SubtransSLRU

等待访问子事务 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件SubtransSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问子事务 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:177。探针覆盖的操作是:等待访问子事务 SLRU 缓存。LWLockAcquire 无法立即取得显示为 SubtransSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SubtransSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SubtransSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SubtransSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

73 - LWLock: SyncRep

等待读取或更新同步复制状态信息。
PostgreSQL 等待事件档案
类别LWLock 事件SyncRep 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新同步复制状态信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

SyncRepLock 保护同步复制队列与共享 sender 状态。提交会话入队或检查等待位置,WAL sender 则更新已被同步备库确认的 LSN。

正常还是麻烦?

  • 正常: 同步提交排队、WAL sender 发布确认位置时会有小规模突发。
  • 需要调查: 持续的 SyncRep LWLock 竞争不同于等待备库确认:它表示队列/状态协调本身过热,通常发生在极高提交并发或 sender 抖动时。

诊断 SQL

正在等待 LWLock/SyncRep 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SyncRep'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SyncRep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 区分 LWLock/SyncRep、IPC/SyncRep 与复制延迟等待。
  2. 检查同步备库健康度、sender 抖动与提交速率。
  3. 稳定复制并平滑提交突发;只有获得明确事故授权时才改变持久性策略。

源码证据

典型事故模式

备库反复抖动,大量同步提交者频繁进出等待队列,使队列协调本身表现为 LWLock/SyncRep。

74 - LWLock: SyncScan

等待选择同步表扫描的起始位置。
PostgreSQL 等待事件档案
类别LWLock 事件SyncScan 版本PG 13-18 证据3 个源码位置

官方描述译文

等待选择同步表扫描的起始位置。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/common/syncscan.c:258。探针覆盖的操作是:等待选择同步表扫描的起始位置。LWLockAcquire 无法立即取得显示为 SyncScan 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SyncScan 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SyncScan'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SyncScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

75 - LWLock: TablespaceCreate

等待创建或删除表空间。
PostgreSQL 等待事件档案
类别LWLock 事件TablespaceCreate 版本PG 13-18 证据3 个源码位置

官方描述译文

等待创建或删除表空间。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/tablespace.c:138。探针覆盖的操作是:等待创建或删除表空间。LWLockAcquire 无法立即取得显示为 TablespaceCreate 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/TablespaceCreate 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'TablespaceCreate'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'TablespaceCreate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

76 - LWLock: TwoPhaseState

等待读取或更新预备事务的状态。
PostgreSQL 等待事件档案
类别LWLock 事件TwoPhaseState 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新预备事务的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/twophase.c:329。探针覆盖的操作是:等待读取或更新预备事务的状态。LWLockAcquire 无法立即取得显示为 TwoPhaseState 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/TwoPhaseState 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'TwoPhaseState'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'TwoPhaseState'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

77 - LWLock: WALBufMapping

等待替换 WAL buffer 中的页面。
PostgreSQL 等待事件档案
类别LWLock 事件WALBufMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待替换 WAL buffer 中的页面。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

WALBufMappingLock 协调 WAL 页号与有限 wal_buffers 槽位之间的映射。后端推进到新 WAL 页或替换缓冲页时需要取得此锁。

正常还是麻烦?

  • 正常: WAL 生成推进并跨越缓冲页时会短暂出现。
  • 需要调查: 持续竞争说明 WAL 生成换页速度超过写路径推进速度,常见于写突发或检查点期间。

诊断 SQL

正在等待 LWLock/WALBufMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALBufMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALBufMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 关联 WAL 字节量、WAL 写入与检查点时间。
  2. 检查写突发期间 wal_buffers 是否反复耗尽。
  3. 先平滑写突发并解决 WAL 设备延迟,再调整缓冲区大小。

源码证据

典型事故模式

批量导入把 WAL 生成推到极限,同时 WAL 设备发生停顿,导致频繁的 WAL 缓冲页重映射。

78 - LWLock: WALInsert

等待将 WAL 数据插入内存 buffer。
PostgreSQL 等待事件档案
类别LWLock 事件WALInsert 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将 WAL 数据插入内存 buffer。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

后端在共享 WAL 缓冲区中预留空间并复制 WAL 记录时,必须持有一个 WAL insertion lock。并发 WAL 生产者很多、插入临界区变长时,会在此排队。

正常还是麻烦?

  • 正常: 并发写入与提交突发期间的瞬时等待很正常。
  • 需要调查: 前台会话反复堆积说明 WAL 插入已成为串行点,常伴随极高写并发、全页镜像或缓冲区换页过慢。

诊断 SQL

正在等待 LWLock/WALInsert 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALInsert'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALInsert'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按 WAL 生成量与调用频率排序语句。
  2. 检查检查点/全页镜像时机与并发写会话数量。
  3. 批量合并微小写入、减少无效索引抖动,并处理 WAL 写延迟。

源码证据

典型事故模式

扇出任务在检查点后立即发起大量单行提交,全页镜像与写并发共同让 WAL 插入成为瓶颈。

79 - LWLock: WALSummarizer

等待读取或更新 WAL 汇总状态。
PostgreSQL 等待事件档案
类别LWLock 事件WALSummarizer 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新 WAL 汇总状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/walsummarizer.c:273。探针覆盖的操作是:等待读取或更新 WAL 汇总状态。LWLockAcquire 无法立即取得显示为 WALSummarizer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WALSummarizer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALSummarizer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALSummarizer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

80 - LWLock: WALWrite

等待将 WAL buffer 写入磁盘。
PostgreSQL 等待事件档案
类别LWLock 事件WALWrite 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将 WAL buffer 写入磁盘。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

WALWriteLock 串行化共享 WAL 缓冲区写入,以及 written/flushed 位置的推进。等待者正在当前执行或协调这项工作的后端之后排队。

正常还是麻烦?

  • 正常: 多个提交者协助写 WAL 时会短暂出现。
  • 需要调查: WALWrite 持续出现且提交延迟上升,通常表示 WAL 写路径变慢,或吞吐跟不上 WAL 生成速度。

诊断 SQL

正在等待 LWLock/WALWrite 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALWrite'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 把 WAL write/sync 时间与提交延迟对照。
  2. 检查 WAL 文件系统/设备、虚拟化限速与检查点重叠。
  3. 降低突发性;只有存储证据确认后才调整 wal_writer 参数。

源码证据

典型事故模式

云盘耗尽突发积分,WAL 写入变长,提交会话在 WALWrite 上排队,同步提交延迟同步恶化。

81 - LWLock: WaitEventCustom

等待读取或更新自定义等待事件信息。
PostgreSQL 等待事件档案
类别LWLock 事件WaitEventCustom 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新自定义等待事件信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:193。探针覆盖的操作是:等待读取或更新自定义等待事件信息。LWLockAcquire 无法立即取得显示为 WaitEventCustom 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WaitEventCustom 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WaitEventCustom'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WaitEventCustom'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

82 - LWLock: WrapLimitsVacuum

等待更新事务 ID 和 multixact 的消耗上限。
PostgreSQL 等待事件档案
类别LWLock 事件WrapLimitsVacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新事务 ID 和 multixact 的消耗上限。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/vacuum.c:1858。探针覆盖的操作是:等待更新事务 ID 和 multixact 的消耗上限。LWLockAcquire 无法立即取得显示为 WrapLimitsVacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WrapLimitsVacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WrapLimitsVacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WrapLimitsVacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

83 - LWLock: XactBuffer

等待事务状态 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件XactBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待事务状态 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:140。探针覆盖的操作是:等待事务状态 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 XactBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XactBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

84 - LWLock: XactSLRU

等待访问事务状态 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件XactSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问事务状态 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

事务状态 SLRU 锁保护 pg_xact 缓存元数据与页面,PostgreSQL 读取或更新事务提交状态时会经过这里。对未缓存或很老 XID 的可见性检查会把这条路径带到前台。

正常还是麻烦?

  • 正常: 事务结束与偶发 pg_xact 缓存未命中会带来短暂等待。
  • 需要调查: 持续等待可能表示事务状态缓存抖动、访问很老的元组,或 pg_xact 路径存在存储延迟。

诊断 SQL

正在等待 LWLock/XactSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 检查老事务以及 vacuum/freeze 健康度。
  2. 关联 XactBuffer 与 pg_xact I/O 等待。
  3. 先消除可见性边界阻塞者并恢复清理进度,再考虑容量调整。

源码证据

典型事故模式

长生命周期快照阻止清理,同时查询反复访问冷的旧元组版本,引发 pg_xact 缓存抖动与 XactSLRU 竞争。

85 - LWLock: XactTruncation

等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。
PostgreSQL 等待事件档案
类别LWLock 事件XactTruncation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:357。探针覆盖的操作是:等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。LWLockAcquire 无法立即取得显示为 XactTruncation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XactTruncation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactTruncation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactTruncation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

86 - LWLock: XidGen

等待分配新的事务 ID。
PostgreSQL 等待事件档案
类别LWLock 事件XidGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配新的事务 ID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:105。探针覆盖的操作是:等待分配新的事务 ID。LWLockAcquire 无法立即取得显示为 XidGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XidGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XidGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XidGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据