首页 > 解决方案 > Aurora PostgreSQL 11 - LW:lock:lock_manager 问题

问题描述

目前,我们正在将高吞吐量应用程序从 Oracle 迁移到 AWS Aurora 中的 PostgreSQL 11 数据库。我们已经完成了部分模块的 SQL 查询迁移,目前正在对 PostgreSQL 数据库进行负载测试。

负载测试下的模块为每个事务执行以下活动

在 5 个不同的启用分区的表中大约有 5 个插入/更新操作。每个表将包含近 90 个分区表。不同表中大约有 8 次读取操作,包括启用单分区的表和其余所有未分区的配置表。

我们有一个 PostgreSQL 集群,有一个写入节点 [16 CPU,128 GB RAM] 和一个读取节点 [8 CPU,64 GB]。我们正在使用 AWS RDS 性能监控以及 PGADMIN 工具来监控 PostgreSQL。

我们在 PostgreSQL 中尝试了 30 tps,但集群无法承受这种负载,并且在 30 tps 负载下达到了近 99% 的高 CPU 利用率。我们已经实现了从我们的 Java 客户端应用程序到读取器和写入器节点的双数据源连接,并将选择查询分发到读取器节点。我们能够在读取器和写入器节点的 CPU 利用率为 40% 的情况下实现 75 tps。我们将负载增加了一倍,即 150 tps,然后在负载增加的 3 分钟内 CPU 提升到 99%。

写入操作[插入/更新]以及读取器节点中的选择操作的平均执行时间小于 5 ms。如果调用次数增加,则 CPU 提升至最大值。在我们所有的案例中,我们都可以发现 LWLocks::Lock_manager 进入监控画面,并立即将 CPU 提升到其最大值。如果负载正常,LWLocks::Lock_manager 将在监控洞察图中不可用。

我们还分析了所有查询的解释计划。选择查询直接登陆特定的分区表并获取结果,但更新查询正在扫描所有分区表以查找同一个表。

我们很难找到 CPU 利用率高的根本原因以及 LWLocks::Lock_manager 的触发器。我们正在寻求 PostgreSQL 专家在数据库端评估和性能调整方面的建议和帮助。

标签: postgresql-11amazon-aurora

解决方案


推荐阅读