一次线上CPU和内存占用过高分析

一次线上CPU和内存占用过高分析

引用

CSDN

1.

https://m.blog.csdn.net/fuleigang/article/details/145853587

本文记录了一次系统运行两周后，监控系统频繁发送CPU占比过高，具体分析和后续跟进。

首先登录机器查看具体信息

top - 14:08:46 up 61 days, 7:28, 4 users, load average: 20.24, 18.05, 16.99
Tasks: 309 total, 2 running, 307 sleeping, 0 stopped, 0 zombie
%Cpu(s): 99.2 us, 0.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16265756 total, 198876 free, 15254512 used, 812368 buff/cache
KiB Swap: 16773116 total, 14563704 free, 2209412 used. 154820 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21632 root 20 0 30.263g 0.014t 4116 S 1544 90.7 37889:12 java
1 root 20 0 191984 2276 1264 S 0.0 0.0 0:46.24 systemd

(1) 关键指标解读

• CPU 使用率：

• 99.2% us

• 表示用户空间进程（Java）几乎耗尽所有 CPU。

• 内存使用：

• 15.25GB/16.26GB

• 内存已用，剩余仅 198MB，触发频繁的 Swap 交换（

• 2.2GB/16.77GB

• 已用）。

• 负载平均值：

• 20.24, 18.05, 16.99

• （1/5/15 分钟），远超 CPU 核心数，说明系统严重过载。

• 异常进程：

• java

• 进程占用 1544% CPU（相当于近 16 核满载）和 90.7% 内存（14GB），是核心瓶颈。

查看进程启动命令和路径

ps -ef | grep 21632

查看 Java 应用名称（若通过 jvm 启动）

sudo -u 21632 jps -lv | grep 21632

查看 Java 内存参数配置

ps -ef | grep java | grep -o "\-Xmx[0-9a-zA-Z]*"

[linuxadmin@10-11-24-3 ~]$ ps -ef | grep java | grep -o "\-Xmx[0-9a-zA-Z]*"
-Xmx10g
[linuxadmin@10-11-24-3 ~]$ jps -lv
21572 sun.tools.jps.Jps -Dapplication.home=/data/app/apps/java/jdk1.8.0_111 -Xms8m

分析：
10服务分配了10G内存，实际使用已经14G了，明显超出配置内存，继续分析

检查 Native Memory Tracking 是否启用

jcmd 21632 VM.native_memory summary

[root@10-11-24-3 linuxadmin]# jcmd 21632 VM.native_memory summary
21632: Native memory tracking is not enabled

没有启动 Native Memory Tracking

增加启动参数：
-XX:NativeMemoryTracking=detail

检查进程打开的文件和内存映射

lsof -p 21632 | grep 'mem'

发现运行了较多的三方库和本地依赖，存在依赖重复问题，通过增加内存参数限制

• 限制元空间：添加
  -XX:MaxMetaspaceSize=256m
  防止类元数据无限增长。

• 调整直接内存：若使用 NIO 直接缓冲区，限制
  -XX:MaxDirectMemorySize=1g
  。

• 启用 Native Memory Tracking：重启时添加
  -XX:NativeMemoryTracking=detail
  ，持续监控内存分配。

继续查看进程的使用情况

服务中存在大量的反射，字符串拼接，并发不设置大小，
这个主要还是要通过排查代码来处理，后续分析具体dump结合着来进行整改

再来看看GC情况

• S0: Survivor 0的使用百分比
• S1: Survivor 1的使用百分比
• E: Eden区的使用百分比
• O: 老年代的使用百分比
• M: 元空间（Metaspace）的使用百分比
• CCS: 压缩类空间的使用百分比
• YGC: 年轻代GC次数
• YGCT: 年轻代GC总耗时
• FGC: Full GC次数
• FGCT: Full GC总耗时
• GCT: 所有GC的总耗时，各参数如上

核心问题定位

(1) 年轻代 GC 频繁（YGC 过高）

• 根因：

• Eden 区过小：对象快速填满 Eden 区，触发 YGC。

• 短生命周期对象过多：大量临时对象（如日志字符串、DTO）未被复用。

• Survivor 区无效：S0/S1 存活对象快速晋升老年代（但当前 O 区稳定，说明晋升压力可控）。

• 影响：

• 应用吞吐量下降（频繁 GC 占用 CPU）。

• 局部请求延迟波动（YGC 暂停时间累积）。

(2) Full GC 耗时高（FGCT 单次长）

• 根因：
• 老年代碎片化：CMS/G1 未及时合并碎片，触发 Full GC。
• 堆内存不足：老年代预留空间不足，触发并发模式失败（需结合 GC 日志确认）。

优化建议

(1) 调整年轻代内存分配

• 增大 Eden 区：减少 YGC 频率（根据当前堆配置推测，年轻代可能为默认值）。
  示例（调整前需确认当前 JVM 参数）：

# 假设当前 -Xmx10g，分配 40% 给年轻代（约 4g）
-Xmn4g -XX:SurvivorRatio=8    # Eden=3.5g, S0/S1=0.5g

• 优化 Survivor 区：
  增大 Survivor 区（
  -XX:SurvivorRatio=6
  ）或提高晋升阈值（
  -XX:MaxTenuringThreshold=10
  ）。

(2) 优化对象分配策略

• 复用对象：引入对象池（如 Apache Commons Pool）管理高频创建对象（如日志包装类）。
• 避免大对象直接进入老年代：

-XX:PretenureSizeThreshold=1M    # 对象超过 1MB 才直接进入老年代