Aurora PostgreSQL 11-LW：lock：lock_manager问题

如何解决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的负载下，CPU利用率接近99％。我们已经实现了从Java客户端应用程序到读取器节点和写入器节点的双重数据源连接，并将选择查询分发到读取器节点。使用40％CPU利用率的读取器和写入器节点，我们能够达到75 tps。我们将负载增加了一倍，即150 tps，然后在负载增加3分钟内，CPU提升到了99％。

读取器节点中写入操作[插入/更新]和选择操作的平均执行时间少于5毫秒。如果呼叫数量增加，则CPU提升至最大值。在我们所有的情况下，我们都能发现LWLocks :: Lock_manager可以在监视中显示出来，并立即将CPU提升到最大值。如果负载正常，则LWLocks :: Lock_manager在监视见解图中将不可用。

我们还分析了所有查询的解释计划。选择查询直接进入特定的分区表并获取结果，但更新查询正在扫描所有分区表中的同一张表。

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