ReportPortal数据库连接池优化实践

问题背景

在ReportPortal 24.2版本部署过程中，API容器出现了JDBC连接超时的问题。虽然用户界面没有明显异常，但日志中频繁出现连接超时错误。系统环境为Docker部署的ReportPortal 24.2版本，后端使用AWS RDS PostgreSQL 16数据库。

问题分析

通过日志分析发现，API服务与PostgreSQL数据库之间的连接存在以下特征：

1. 默认连接池大小(27)可能不足以支撑实际业务负载
2. 虽然RDS PostgreSQL的max_connections设置为840，但实际并发连接数峰值达到140左右
3. 数据库监控显示存在约400秒的连接延迟
4. 测试状态偶尔会变为"Interrupted"

解决方案

连接池优化

核心解决措施是调整API服务的连接池配置：

1. 增加API服务的环境变量：

RP_DATASOURCE_MAXIMUMPOOLSIZE=100

这一调整使得连接池从默认的27增加到100，有效解决了连接超时问题。调整后，系统活跃连接数从66上升到140，连接延迟问题得到明显改善。

数据库参数优化建议

虽然当前配置已解决问题，但针对AWS RDS PostgreSQL，还有以下优化空间：

1. 合理设置max_connections参数（建议从840降至500）

   • 每个连接消耗5-10MB内存
   • 过多连接会导致CPU上下文切换开销增加

2. 针对硬件规格的推荐配置（以16CPU/32GB内存为例）：

   • shared_buffers = '8GB'
   • effective_cache_size = '24GB'
   • max_worker_processes = '16'
   • max_parallel_workers = '16'

实施效果

实施连接池优化后，系统表现出以下改进：

1. JDBC连接超时错误消失
2. 测试状态不再出现"Interrupted"异常
3. 数据库连接数稳定在合理范围
4. 系统整体性能更加稳定

经验总结

1. ReportPortal在高负载场景下，默认连接池配置可能不足，需要根据实际负载调整
2. 数据库连接数不是越大越好，需要平衡内存消耗和CPU开销
3. 对于AWS RDS，除了连接池外，还应关注参数组的优化配置
4. 监控数据库连接数和延迟指标是发现此类问题的有效手段

通过这次优化实践，我们验证了合理配置连接池对于ReportPortal稳定运行的重要性，也为类似环境下的性能调优提供了参考方案。