CentOS 上 WebLogic 资源占用高的排查与优化
一 快速定位占用来源
- 先看系统层面整体负载：用 top/htop 观察 CPU、内存、I/O 是否异常；用 vmstat 1 5 检查 si/so（换入换出）、wa（I/O 等待）；用 iostat -x 1 查看磁盘 util% 与 await。这些指标能快速判断是 CPU 计算密集、内存不足导致频繁换页，还是磁盘/网络 I/O 成为瓶颈。
- 再看 WebLogic 内部：登录控制台或使用 WLST 查看 线程池当前大小、增长/收缩计数、等待计数，观察 队列长度 是否长期不为 0；检查 JDBC 连接池 的使用率、等待与超时；确认是否启用 Native IO；必要时调高 Accept Backlog 以避免在高并发下出现连接拒绝。
- 若是内存问题：开启 -verbose:gc 观察 GC 频率与停顿；用 jstat -gcutil 1000 10 查看各区使用与 GC 行为；一旦出现 OOM，使用 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=… 生成 HPROF 堆转储，再用 Eclipse MAT 分析泄漏对象与引用链。
二 常见高占用场景与对策
| 场景 |
典型现象 |
优先动作 |
| JVM 堆内存不足/泄漏 |
频繁 Full GC、响应变慢、出现 OutOfMemoryError |
设置 -Xms=-Xmx（如 -Xms4g -Xmx4g），选用 G1 GC；开启 HeapDumpOnOutOfMemoryError 并用 MAT 定位泄漏；必要时优化应用对象生命周期与缓存策略 |
| 线程池/请求队列拥堵 |
控制台 Queue Length 持续大于 0、线程忙碌时间长 |
监控线程池的 current size/grow/shrink/wait，逐步调大线程上限；优化慢 SQL/慢接口；检查并处置 Stuck Thread（长时间卡住的工作线程） |
| JDBC 连接池瓶颈 |
连接等待、超时、数据源活跃数长期接近上限 |
合理设置 InitialCapacity≈MaxCapacity，避免运行期频繁扩容；开启 PreparedStatement Cache；结合业务并发调优连接池大小 |
| 文件描述符/端口耗尽 |
新连接失败、日志出现 “Too many open files” |
提升 ulimit -n（如 65535），并在 /etc/security/limits.conf 持久化；必要时增大 Accept Backlog |
| 网络/磁盘 I/O 瓶颈 |
iostat util%≈100%、await 高、吞吐上不去 |
优化 SQL/索引、启用缓存；考虑更快存储（如 SSD）、优化文件系统挂载选项（如 noatime）、必要时升级网卡/调整队列与缓冲区 |
以上动作涉及的参数与位置要点：JVM 堆与 GC 在 setDomainEnv.sh 中设置；线程池与队列、数据源、Native IO、Accept Backlog 可在控制台或 WLST 调整；系统级限制在 /etc/security/limits.conf 与内核参数中设置。
三 关键参数与配置示例
- JVM 与 GC
- 建议将 -Xms 与 -Xmx 设为相同值（如 -Xms4g -Xmx4g），减少堆扩展带来的抖动；优先选用 G1 GC（如 -XX:+UseG1GC）。
- 发生 OOM 时开启 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dumps/heap.hprof，用 MAT 分析 dominator tree 与引用链。
- 线程池与队列
- WebLogic 9.x+ 采用 自调优线程池，以监控指标（当前大小、增长/收缩、等待）为依据做渐进式调整，避免一次性大幅改动。
- 若出现大量 Stuck Thread，先定位根因（慢 SQL/外部依赖/死循环），再考虑适度增大线程上限与优化代码路径。
- JDBC 与事务
- 开启 PreparedStatement Cache，减少硬解析；对以数据库为主的两阶段事务，优先考虑 Logging Last Resource（LLR） 优化以替代 XA，降低提交开销。
- 网络与文件句柄
- 提升 文件描述符限制：如 * soft/hard nofile 65535；在 /etc/security/limits.conf 持久化。
- 调高 Accept Backlog（如从默认 50 起按 25% 逐步递增），缓解高并发下的连接拒绝。
- 内核网络参数示例：net.ipv4.tcp_tw_reuse=1、net.ipv4.tcp_fin_timeout=30，执行 sysctl -p 生效。
四 稳妥的优化流程
- 建立基线：用 JMeter/LoadRunner 压测，记录 CPU、内存、I/O、吞吐、响应时间、线程池/队列 等指标，作为对比依据。
- 小步迭代：一次只调整一个变量（如线程数或连接池容量），每次变更后回归压测，确认收益与副作用。
- 灰度与回滚：先在测试/预发环境验证，再灰度上线；保留回滚方案与变更记录。
- 持续监控：在生产侧常态化监控 GC、线程池、连接池、队列、I/O，并设置阈值告警，提前识别回退与再优化时机。
五 注意事项
- 堆转储与分析会显著增加 JVM 暂停时间，务必在低峰期执行，避免影响业务。
- 线程池、连接池并非越大越好，应与 CPU 核数、数据库并发能力、外部依赖 综合匹配，避免放大下游瓶颈。
- 任何参数变更前做好配置备份与回滚预案，变更后在相同负载下复核关键指标，确保稳定性与安全性。