Ubuntu 上 WebLogic 数据库连接优化指南
一 连接池容量与等待策略
- 合理设定容量边界：将InitialCapacity设为应用高峰期的稳态并发连接数；将Maximum Capacity设置为不超过数据库最大连接数的80%，避免把数据库压满。按负载逐步调大 Maximum Capacity，确保峰值期也能获取连接。
- 平滑扩容与回缩：设置Capacity Increment（如每次扩容5个），减少抖动；结合业务低谷期允许Shrink回收空闲连接，避免长期占用。
- 启用等待与回压控制：开启连接请求的等待机制，配置Connection Reserve Timeout（获取连接的等待超时）与Maximum Waiting for Connection（最大排队等待线程数），既防止雪崩，又避免线程无限阻塞。
- 连接有效性保障：启用Test Connections on Reserve（借用连接时校验有效性），并配置Test Table Name（如 Oracle 使用“SQL SELECT 1 FROM DUAL”），及时剔除失效连接。
- 泄漏治理：开启Remove Infected Connections Enabled，在连接归还时重建“被感染”的连接，降低脏连接风险。
- 语句级超时：设置Statement Timeout，限制单条 SQL 执行时间，防止长事务/慢查询拖垮连接池。
以上参数可在控制台：服务 → 数据源 → 选择数据源 → 配置 → 连接池中调整。
二 高级特性与典型场景
- 线程绑定连接（Pinned To Thread）：对短事务、极高并发、线程争用明显的场景，可将Pinned To Thread设为true，把连接“粘”在执行线程上，显著降低取连接锁竞争。启用后：
- Maximum Capacity 被忽略，连接数≈max(InitialCapacity, 线程绑定连接数)；
- Shrinking 不生效（连接不会回到池中）；
- 需开启Test Connections on Reserve并配置Test Table Name，在 Reset 或首次借用时按需测试重建；
- 与IdentityPool不兼容（会导致部署失败）。
- 典型取舍：Pinned To Thread 能减少连接争用与获取延迟，但会显著增加数据库端会话/连接数，需评估数据库许可与会话上限后再启用。
三 Ubuntu 系统层面的配套优化
- 文件描述符与内核资源：提升进程可打开文件数（如ulimit -n 65535），并在**/etc/security/limits.conf中持久化；适度降低vm.swappiness**（如10），减少换页对稳定性的影响。
- 网络栈优化：提高net.core.somaxconn，开启net.ipv4.tcp_tw_reuse=1，提升高并发下的连接处理能力。
- 存储与 I/O：优先使用SSD；文件系统选XFS/EXT4并挂载noatime,nodiratime；SSD 推荐noop调度器，机械盘可用deadline。
- 监控手段：结合top/htop、vmstat、iotop与 WebLogic 控制台监控，定位瓶颈后再微调连接池与系统参数。
这些系统级优化能为连接池的高并发获取与网络往返提供底层支撑。
四 监控与排障要点
- 连接与等待指标：在控制台监控数据源的当前占用、等待线程数、等待超时、借用/归还速率、Statement Timeout 命中等，验证扩容与超时策略是否有效。
- 语句级控制与驱动兼容：设置Statement Timeout后，WebLogic 会通过**java.sql.Statement.setQueryTimeout()**传递给驱动；不同驱动支持程度不一，需查阅驱动文档确认行为。
- 连接泄漏定位：开启Remove Infected Connections Enabled与有效性测试，配合应用日志与 JDBC 代理/拦截器，识别未关闭的 Connection/Statement/ResultSet。
- 变更流程：先在测试环境验证参数组合（容量、等待、超时、Pinned To Thread），再灰度上线，观察DB 会话数、连接等待、RT、错误率的联动变化，逐步固化到生产。