首先直接给结论：你完全可以将jdbc/ICWS资源的最大连接数调整到200甚至更高，但需要结合数据库端的支撑能力和服务器剩余资源做逐步验证，同时通过监控来找到最适合的理想值

基于当前服务器规格的可行性分析 #

你的LPAR服务器总内存14GB，已使用12GB，剩余2GB可用；WebSphere的Java堆最大设置为2560MB（2.5GB）。这里需要明确：JDBC连接池的连接实例通常不会占用WebSphere的Java堆内存，而是占用操作系统的本地内存，每个JDBC连接的内存开销大概在5-10MB左右（不同数据库驱动略有差异）。

按200个连接计算，总内存开销大概在1-2GB，刚好落在剩余的2GB可用内存范围内，理论上是完全可行的。不过调整后要密切监控LPAR的内存使用率，避免出现内存耗尽触发系统swap的情况——如果发现内存占用接近阈值，可以适当降低连接数，或者优化其他内存占用高的组件。

如何确定连接池的理想值 #

理想的最大连接数不是固定数值，需要结合你的业务场景和系统负载来确定，参考以下步骤：

• 匹配并发需求底线：你的Web服务需要处理125个并发请求，假设每个请求都需要独立的JDBC连接，那么最大连接数至少要设置为125。为了应对突发流量和连接复用的损耗，建议先设置为150（增加20%的冗余缓冲），而不是直接跳到200。
• 对齐数据库端的能力：不要只调整WebSphere的连接池，必须同步确认数据库的最大连接数设置——如果数据库只允许150个并发连接，WebSphere设200也会出现连接等待的问题，两边的数值要匹配。
• 通过监控动态调优：设置初始值后，监控WebSphere控制台里的连接池指标：
  • 连接等待时间（如果持续高于阈值，说明连接数还是不够）
  • 连接使用率（如果长期低于70%，说明连接数设置过高，浪费资源）
  • 空闲连接回收情况（确保闲置连接能被及时释放）
    根据监控数据逐步微调，最终找到既能满足并发需求，又不会过度消耗资源的数值。

额外注意事项 #

• 不要一次性把连接数调到过高（比如500），避免突然给数据库和服务器带来过大负载，建议分阶段调整（比如从50→125→150→200），每调整一次就观察一段时间系统运行情况。
• 再次检查连接池的其他参数：比如连接超时时间、空闲连接超时时间、连接复用规则，确保连接能被高效复用，减少不必要的连接创建和等待。
• 虽然你已经排查过连接泄漏，但调整连接数后还是要持续监控，避免因为潜在的泄漏问题导致连接被耗尽。

内容的提问来源于stack exchange，提问作者Shinoy Shaji