有大佬碰到过lwlock. Lock_manager 等待事件吗？压测，大并发。

在高并发压测场景中遇到lwlock: Lock_manager等待事件，这通常与PostgreSQL数据库内部的锁管理有关。Lock Manager负责处理各种锁请求，包括共享锁、排他锁等，以维护数据库的事务隔离性和一致性。在大并发情况下，锁的竞争可能会变得激烈，导致某些事务需要等待锁资源释放，从而出现此类等待事件。

针对您提到的问题，这里提供一些建议和排查方向：

1. 并发控制与锁优化：

   • 检查并优化应用层面的事务设计，减少长事务操作，避免不必要的锁持有时间过长。
   • 使用更细粒度的锁，如果可能，通过合理设计索引或利用行级锁来减少锁冲突。
   • 考虑使用乐观锁策略，在适用的业务场景下减少对数据库锁的依赖。

2. 数据库参数调优：

   • 适当调整数据库的锁相关参数，如max_locks_per_transaction和max_connections，以适应更高的并发需求。但请注意，这些调整需基于当前系统资源和负载情况仔细评估，以免引发其他问题。

3. 监控与诊断：

   • 利用PostgreSQL的内置监控工具（如pg_stat_activity, pg_locks视图）定期检查锁等待情况，识别频繁产生锁竞争的查询或事务。
   • 结合阿里云AnalyticDB PostgreSQL版实例性能测试时的配置经验，分析压测数据，确认是否由于压测设置（如并发数、RPS限制）不当导致数据库锁争用加剧。

4. 资源扩展与配置：

   • 根据压测报告和实际压力情况，适时增加数据库实例的计算资源，或者采用读写分离、分片等架构优化手段分散负载。
   • 确认压测工具（如PTS）的施压配置没有成为瓶颈，根据需要调整最大并发数、RPS限制等，确保压测能够准确反映系统极限而不受工具本身的限制。

5. 压测策略调整：

   • 在进行压力预估和压测设计时，参考并发自动递增模式下的压力预估图策略，合理规划数据准备阶段与全链路压测的时机与量级，确保模拟真实用户行为的同时，有效识别和解决锁竞争问题。

综上所述，解决lwlock: Lock_manager等待事件的关键在于理解并优化数据库的并发控制机制，结合应用逻辑、数据库配置及压测策略的综合调整。务必在生产环境调整前，充分测试各项改动，以避免影响业务连续性。