怎样优化Ubuntu上WebLogic性能

Ubuntu上WebLogic性能优化实操指南

一 系统层优化

• 资源与监控
  • 使用top/htop观察CPU、内存与负载；用vmstat、iostat、sar持续监测系统瓶颈；必要时用cgroups限制容器/进程资源，避免单实例过度占用。
• 文件与I/O
  • 选择适合业务的文件系统（如ext4/xfs/btrfs），并通过iotop/vmstat定位磁盘热点与I/O等待。
• 内存与OOM
  • 通过**/proc//oom_score_adj降低关键进程被OOM Killer终止的风险；在内存紧张环境下可启用zram/zswap**提升可用物理内存与稳定性。
• 网络栈与连接
  • 适度提升TCP相关内核参数以支撑高并发连接与短连接场景：
    • net.core.netdev_max_backlog：提升网卡待处理队列（如8096或更高）。
    • net.core.somaxconn：提升全连接队列上限（如8096或更高）。
    • net.ipv4.tcp_keepalive_time / tcp_keepalive_intvl：缩短无效连接探测间隔（如1800秒/30秒）。
    • net.ipv4.tcp_tw_reuse / tcp_tw_recycle（谨慎启用，按内核版本与场景评估）：加速TIME_WAIT回收。
    • 注意：修改内核参数需结合负载压测逐步验证，避免一次性大幅变更。

二 JVM与启动参数

• 运行模式
  • 生产环境务必使用产品模式（PRODUCTION_MODE=true），其默认队列与连接池容量更贴近生产需求（如Execute Queue ThreadCount：开发15、产品25；JDBC MaxCapacity：开发15、产品25）。
• 堆与内存
  • 在域目录的bin/setDomainEnv.sh或启动脚本中设置堆大小，建议**-Xms=-Xmx**（避免运行期扩缩堆带来的抖动），并预留足够堆外内存给元空间/本地内存与线程栈。
  • 示例（按物理内存与GC策略调整）：
    • WLS_MEM_ARGS_64BIT=“-Xms4g -Xmx4g”
    • WLS_MEM_ARGS_32BIT=“-Xms2g -Xmx2g”
• 启动加速
  • 老版本JDK在Linux上可能因熵源不足导致启动缓慢，可编辑**$JAVA_HOME/jre/lib/security/java.security**，将
    • securerandom.source=file:/dev/urandom
    • 改为：securerandom.source=file:/dev/./urandom
• 文件句柄与进程数
  • 提升用户级资源限制，编辑**/etc/security/limits.conf**：
    • • soft nofile 65535
    • • hard nofile 65535
    • • soft nproc 65535
    • • hard nproc 65535
  • 调整后需重新登录或重启相关服务生效。

三 WebLogic内部关键参数

• 执行线程与工作队列
  • 通过控制台或config.xml调整：
    • Execute Queue 的Thread Count：以25 × CPU核心数为基准，结合压测逐步微调；避免过大导致上下文切换激增。
    • 溢出策略：合理设置Queue Length Threshold Percent / Threads Increase / Threads Maximum，防止雪崩与线程失控。
    • 阻塞线程：Stuck Thread Max Time（默认600秒）与Stuck Thread Timer Interval（默认600秒）用于识别与处置长时间阻塞线程。
• I/O与网络
  • 启用Native IO（NativeIOEnabled=true）提升网络吞吐；若不可用，调整Socket Readers百分比（默认约33%）。
  • 提升Accept Backlog（默认50）以缓冲突发连接，通常可按需逐步上调并观察“Connection Refused”是否消失。
• JDBC连接池
  • 设置InitialCapacity≈MaxCapacity（减少运行期扩容抖动），并将MaxCapacity与执行线程数匹配或略高，避免线程空转等待连接。
  • 合理设置StatementCacheSize，避免过大导致内存与元数据压力。

四 监控与容量规划

• 内置监控与诊断
  • 使用WebLogic Administration Console与Performance Monitoring观察线程池、队列、JDBC、JVM等关键指标；结合Stuck Thread告警与GC日志定位瓶颈。
• 系统与中间件观测
  • 持续采集CPU、内存、I/O、网络、句柄、线程等指标，配合Prometheus + Grafana构建可视化与告警，形成闭环优化。

五 快速检查清单与推荐起点

• 运行模式为产品模式；堆**-Xms=-Xmx且避开系统内存过度占用（通常不超过物理内存的50%~60%**，视容器/宿主机而定）。
• 执行线程以25 × CPU核心数为起点，压测中按吞吐与CPU利用率微调；必要时启用溢出策略与阻塞线程监控。
• 启用Native IO；Accept Backlog从50起步逐步上调；JDBC MaxCapacity≈线程数并开启Statement Cache。
• 提升文件句柄/进程数限制；按需开启zram/zswap与内核网络参数优化；老版本JDK启用**/dev/./urandom**加速启动。
• 建立监控与基线，每次变更后进行回归压测与容量评估，确保稳定与可观测性。