Ubuntu上 WebLogic 性能调优最佳实践
一 系统层优化
- 资源与监控
- 使用 top/htop 观察 CPU、内存与负载；用 vmstat、iostat、sar 持续监测系统瓶颈；必要时用 cgroups 限制容器/实例资源，避免单实例拖垮整机。
- 文件描述符与内核参数
- 提升进程可打开文件数与内核网络/文件缓存参数，编辑 /etc/security/limits.conf：
- 示例：* soft/hard nofile 65535；* soft/hard nproc 65535
- 按需增大内核可调参数（示例，需结合压测微调）：
- fs.file-max、net.core.somaxconn、net.ipv4.tcp_tw_reuse、net.ipv4.tcp_fin_timeout
- 内存与交换策略
- 避免 OOM 误杀关键进程，合理设置 oom_score_adj；在内存紧张但需保活场景启用 zram/zswap 提升可用物理内存与稳定性。
- I/O 与文件系统
- 选择适合业务特征的 ext4/xfs/btrfs；用 iotop 定位高 I/O 进程与热点文件，必要时做磁盘调度与条带化优化。
二 JVM 与启动优化
- 堆与模式
- 将最小与最大堆设为相等（如 -Xms4g -Xmx4g）以减少堆扩展抖动；生产环境启用 PRODUCTION_MODE=true 获取更保守且面向生产的默认配置。
- 随机数源加速
- 若出现启动缓慢（随机数初始化阻塞），在 $JAVA_HOME/jre/lib/security/java.security 中将
- securerandom.source=file:/dev/urandom 改为 securerandom.source=file:/dev/./urandom
- 内存参数位置
- 优先在域目录的 bin/setDomainEnv.sh 中设置 WLS_MEM_ARGS_64BIT/WLS_MEM_ARGS_32BIT；也可在 startWebLogic.sh 中通过 MEM_ARGS 覆盖。
- 堆大小经验值
- 最大堆一般不超过物理内存的 50%~60%，单实例通常不超过 8G（需结合 GC 策略与负载实测）。
三 WebLogic 服务器与数据源调优
- 执行线程与工作队列
- 结合 CPU 与 I/O 能力设置执行线程数；经验上每个 CPU 不超过 ~50 个线程，过高会因上下文切换导致吞吐下降。
- 开启 Native IO（控制台：Servers > server > Configuration > Tuning）以利用多路复用与本地 I/O，减轻默认队列压力。
- 调整 Accept Backlog（接受缓存数）：默认 50，当出现 Connection Refused 时可按 25% 步进上调，直至拒绝消失（受 OS 上限约束）。
- 配置 Stuck Thread（堵塞线程）阈值与间隔，及早识别长耗时请求并定位根因（SQL、外部依赖、锁等）。
- 数据源与事务
- 合理设置 JDBC 连接池 InitialCapacity/MaxCapacity，建议生产上将 InitialCapacity=MaxCapacity，避免运行期频繁建连；开启 PreparedStatement Cache 减少硬解析。
- 事务优化：对以数据库为主的两阶段提交场景，优先考虑 Logging Last Resource（LLR） 替代 XA，降低 2PC 开销并提升吞吐。
四 网络与协议参数
- 套接字读写与大数据量
- 针对单次请求处理大量数据的应用，适当增大 WebLogic 网络层的 Chunk Size（客户端与服务端两侧一致），减少系统调用与拷贝次数，提高大对象传输吞吐。
- TCP 连接与超时
- 结合并发与短连/长连特征，适度提升 Accept Backlog；对普通与 SSL 登录超时分别设置 Login Timeout/SSL Login Timeout，避免异常断开与握手堆积。
五 监控验证与迭代
- 内置监控与诊断
- 使用 WebLogic Administration Console / Performance Monitoring 观察 Queue Length、吞吐、线程利用率、JDBC 活动 等关键指标；结合 Stuck Thread 告警定位慢请求与阻塞点。
- 系统与应用观测
- 以 vmstat、iostat、sar、iotop 持续采集系统层指标；必要时引入 Prometheus + Grafana 构建可视化与告警，形成“压测—观测—调参—复测”的闭环。