Ubuntu上WebLogic运行慢的排查与优化清单
一 快速定位瓶颈
- 资源与负载：用top/htop观察CPU、内存、负载；用vmstat、iostat、sar持续监测系统层瓶颈；必要时用cgroups限制/隔离WebLogic资源，避免影响其他业务。
- 磁盘与I/O：用iotop定位高I/O进程，检查**/var/log、域目录、数据库日志是否频繁刷盘；结合业务选择合适的ext4/xfs/btrfs**并关注I/O等待。
- JVM与GC：开启GC日志，观察Full GC频率与停顿；确认堆大小是否合理、是否存在内存泄漏。
- WebLogic内部：在Administration Console查看线程池、JDBC连接池、Servlet/JSP等运行时指标，识别线程饥饿、连接不足、阻塞等。
- 网络：检查TCP重传、连接时延，确认是否受网络抖动影响。
以上做法可快速判断是系统资源、I/O、JVM还是应用/配置导致的慢。
二 高概率原因与对应修复
- 启动或创建域阶段卡住（熵池不足导致随机数阻塞）：
修改WebLogic使用的JDK安全配置，将**$JAVA_HOME/jre/lib/security/java.security中的
securerandom.source=file:/dev/urandom 改为
securerandom.source=file:/dev/./urandom；或在setDomainEnv.sh**中添加
JAVA_OPTIONS=“${JAVA_OPTIONS} -Djava.security.egd=file:/dev/./urandom” 并导出。此法可显著缩短启动/建域时间。
- 运行期线程不足或过载：
在控制台调优执行队列线程数（WebLogic 12c之后以Work Managers为主，思路一致），经验上以CPU核心数 × 50为上限进行压测寻优，避免线程过多导致上下文切换开销。
- JDBC连接池瓶颈：
将连接池的初始容量=最大容量，并把最大容量设置为至少与线程数相当，减少运行时扩容与等待。
- 文件描述符与进程数限制：
编辑**/etc/security/limits.conf**，为运行WebLogic的用户设置如：
soft/hard nofile 65535；soft/hard nproc 65535，防止“Too many open files”。
- 网络半连接队列过小：
在config.xml的Server配置中提升Accept Backlog（默认约50），可按负载逐步上调（如每次**+25%**）以减少连接拒绝。
- 未启用本地I/O性能包：
在控制台“服务器 > 配置 > 调整”启用Native I/O（NativeIOEnabled=true），可降低网络栈开销、提升吞吐。
- 内存配置不当：
在setDomainEnv.sh中设置**-Xms与-Xmx相等（如各4G**），一般建议堆不超过物理内存的50%~60%，避免频繁GC或OOM。
三 关键配置示例
- setDomainEnv.sh（JVM与熵源）
# 堆大小：建议Xms=Xmx，且不超过物理内存的50%~60%
WLS_MEM_ARGS_64BIT="-Xms4g -Xmx4g"
export WLS_MEM_ARGS_64BIT
# 加速启动/建域阶段的熵源初始化
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.egd=file:/dev/./urandom"
export JAVA_OPTIONS
- limits.conf（放宽句柄与进程数）
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
- config.xml（网络与I/O）
<Server>
...
<AcceptBacklog>100</AcceptBacklog>
<NativeIOEnabled>true</NativeIOEnabled>
</Server>
- JDBC连接池（示例原则）
- 初始容量=最大容量（减少运行时扩容）
- 最大容量 ≥ 执行队列/工作线程数（避免线程等待连接）
四 验证与持续监控
- 基线对比：在调整前后记录相同场景下的RT、TPS、95/99分位延迟、Full GC次数/停顿、CPU/IO等待，以数据评估优化成效。
- 运行期观测：在控制台持续关注线程池使用率、队列等待、JDBC活跃/等待连接、Servlet/JSP编译与缓存命中等指标，结合业务高峰做滚动调优。
- 系统层监控：使用Prometheus + Grafana构建可视化监控，覆盖CPU、内存、I/O、网络、JVM等关键维度，设置阈值告警，形成持续优化闭环。