问题描述
当前，我们正在将高吞吐量应用程序从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专家的有关数据库方面评估和性能调整的建议和帮助。
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）