PostgreSQL 谁堵塞了谁(锁等待检测)- pg_blocking_pids

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 标签 PostgreSQL , 锁等待 , 队列 背景 1 "被害人" 1、找到"被害人",获取被锁堵塞的PID select distinct pid from pg_locks where not granted; 2、找到"嫌疑人",获取被锁堵塞的PID是被哪些PID堵塞的 postgres=# select * from pg_blocking_pids(5392

标签

PostgreSQL , 锁等待 , 队列


背景

1 "被害人"

1、找到"被害人",获取被锁堵塞的PID

select distinct pid from pg_locks where not granted;  

2、找到"嫌疑人",获取被锁堵塞的PID是被哪些PID堵塞的

postgres=# select * from pg_blocking_pids(53920);  
 pg_blocking_pids   
------------------  
 {53868}  
(1 row)  

3、找到"被害人" 受侵害的证据

被锁堵塞的PID,当前的会话内容

postgres=# select * from pg_stat_activity where pid=53920;  
-[ RECORD 1 ]----+------------------------------  
datid            | 13285  
datname          | postgres  
pid              | 53920  
usesysid         | 10  
usename          | postgres  
application_name | psql  
client_addr      |   
client_hostname  |   
client_port      | -1  
backend_start    | 2019-03-04 10:20:29.124634+08  
xact_start       | 2019-03-04 10:20:30.962902+08  
query_start      | 2019-03-04 10:20:30.962902+08  
state_change     | 2019-03-04 10:20:30.962905+08  
wait_event_type  | Lock  
wait_event       | relation  
state            | active  
backend_xid      | 1286297005  
backend_xmin     | 1286297004  
query            | drop table a;  
backend_type     | client backend  

被锁堵塞的PID,当前的锁等待内容

postgres=# select * from pg_locks where pid=53920 and not granted;  
 locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction |  pid  |        mode         | granted | fastpath   
----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+---------------------+---------+----------  
 relation |    13285 |  1907887 |      |       |            |               |         |       |          | 5/1358301          | 53920 | AccessExclusiveLock | f       | f  
(1 row)  

2 "嫌疑人"

1、找到"嫌疑人"当前的状态,(注意,有可能当前会话内容看不出侵害动作)

堵塞这个PID的PIDs,当前的会话内容

postgres=# select * from pg_stat_activity where pid= any (pg_blocking_pids(53920));  
-[ RECORD 1 ]----+------------------------------  
datid            | 13285  
datname          | postgres  
pid              | 53868  
usesysid         | 10  
usename          | postgres  
application_name | psql  
client_addr      |   
client_hostname  |   
client_port      | -1  
backend_start    | 2019-03-04 10:20:21.377909+08  
xact_start       | 2019-03-04 10:20:23.832489+08  
query_start      | 2019-03-04 10:20:25.529063+08  
state_change     | 2019-03-04 10:20:25.53116+08  
wait_event_type  | Client  
wait_event       | ClientRead  
state            | idle in transaction  
backend_xid      | 1286297004  
backend_xmin     |   
query            | truncate a;  
backend_type     | client backend  

如果当前状态没有找到具体是哪条SQL干的坏事,则需要从审计日志中查找。

2、找到"嫌疑人"的"犯罪"证据:

堵塞这个PID的PIDs,当前的锁内容

postgres=# select * from pg_locks where pid=any (pg_blocking_pids(53920)) order by pid;  
   locktype    | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction |  pid  |        mode         | granted | fastpath   
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+---------------------+---------+----------  
 virtualxid    |          |          |      |       | 4/1372747  |               |         |       |          | 4/1372747          | 53868 | ExclusiveLock       | t       | t  
 relation      |    13285 |  1907887 |      |       |            |               |         |       |          | 4/1372747          | 53868 | ShareLock           | t       | f  
 relation      |    13285 |  1907887 |      |       |            |               |         |       |          | 4/1372747          | 53868 | AccessExclusiveLock | t       | f  
 transactionid |          |          |      |       |            |    1286297004 |         |       |          | 4/1372747          | 53868 | ExclusiveLock       | t       | f  
(4 rows)  

3 当场对峙

1、"被害人" 对13285.1907887对象需要如下锁

 relation |    13285 |  1907887 |      |       |            |               |         |       |          | 5/1358301          | 53920 | AccessExclusiveLock | f       | f  

2、"嫌疑人" 对13285.1907887对象已持有如下锁

 relation      |    13285 |  1907887 |      |       |            |               |         |       |          | 4/1372747          | 53868 | ShareLock           | t       | f  
 relation      |    13285 |  1907887 |      |       |            |               |         |       |          | 4/1372747          | 53868 | AccessExclusiveLock | t       | f  

两者冲突。

参考

《PostgreSQL 谁堵塞了谁(锁等待检测)- pg_blocking_pids, pg_safe_snapshot_blocking_pids》

《PostgreSQL 锁等待排查实践 - 珍藏级 - process xxx1 acquired RowExclusiveLock on relation xxx2 of database xxx3 after xxx4 ms at xxx》

《PostgreSQL 商用版本EPAS(阿里云ppas(Oracle 兼容版)) NUMA 架构spin锁等待优化》

《PostgreSQL 锁等待监控 珍藏级SQL - 谁堵塞了谁》

《PostgreSQL 锁等待跟踪》

 

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
SQL 关系型数据库 MySQL
MySQL - 锁等待及死锁初探
MySQL - 锁等待及死锁初探
175 0
|
5月前
|
SQL 关系型数据库 MySQL
MySQL中锁等待超时与information_schema的三个表
MySQL中锁等待超时与information_schema的三个表
68 0
|
SQL 存储 Oracle
19 PostgreSQL 锁类型,锁模式,锁冲突,死锁检测的介绍|学习笔记
快速学习19 PostgreSQL 锁类型,锁模式,锁冲突,死锁检测的介绍
679 0
19 PostgreSQL 锁类型,锁模式,锁冲突,死锁检测的介绍|学习笔记
|
运维 关系型数据库 MySQL
MySQL锁等待与死锁问题分析
在 MySQL 运维过程中,锁等待和死锁问题是令各位 DBA 及开发同学非常头痛的事。出现此类问题会造成业务回滚、卡顿等故障,特别是业务繁忙的系统,出现死锁问题后影响会更严重。本篇文章我们一起来学习下什么是锁等待及死锁,出现此类问题又应该如何分析处理呢?
519 0
|
SQL 存储 关系型数据库
Mysql事物锁等待超时 Lock wait timeout exceeded; try restarting transaction
Mysql事物锁等待超时 Lock wait timeout exceeded; try restarting transaction
683 0
|
SQL 弹性计算 监控
PostgreSQL 谁堵塞了谁(锁等待检测)- pg_blocking_pids, pg_safe_snapshot_blocking_pids
标签 PostgreSQL , 锁等待 , 队列 背景 当一个进程处于等待(被堵塞)状态时,是谁干的?可以使用如下函数,快速得到捣蛋(堵塞别人)的PID。 1、请求锁时被堵,是哪些PID堵的? pg_blocking_pids(int) int[] Process ID(s) that are blocking specified server process ID from acq
1698 0
|
存储 SQL 关系型数据库
【学习资料】第16期快速入门PostgreSQL应用开发与管理 - 6 事务和锁
大家好,这里是快速入门PostgreSQL应用开发与管理 - 6 事务和锁
|
SQL 监控 安全
PostgreSQL 谁堵塞了谁(锁等待检测)- pg_blocking_pids, pg_safe_snapshot_blocking_pids
PostgreSQL 谁堵塞了谁(锁等待检测)- pg_blocking_pids, pg_safe_snapshot_blocking_pids
1916 0
|
17天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
19天前
|
存储 SQL 关系型数据库
使用MySQL Workbench进行数据库备份
【9月更文挑战第13天】以下是使用MySQL Workbench进行数据库备份的步骤:启动软件后,通过“Database”菜单中的“管理连接”选项配置并选择要备份的数据库。随后,选择“数据导出”,确认导出的数据库及格式(推荐SQL格式),设置存储路径,点击“开始导出”。完成后,可在指定路径找到备份文件,建议定期备份并存储于安全位置。
159 11

热门文章

最新文章

下一篇
无影云桌面