前端崩溃分析
- 前端请求携带大量产品 ID 拼接到 URL，导致 URL 超长请求失败
📌 压测场景说明
- 压测入口接口：/batchChannelProduct/save
- 数据量级：Excel 文件中包含 69 条产品对接配置数据
- 预期效果：请求能在合理时间内完成，资源使用无明显异常，功能逻辑正确
📊 资源监控结果
1. 📈 CPU & Memory 使用趋势图（每秒采样）
历史图片占位：Pasted image 20250721172208.png 历史图片占位：Pasted image 20250721172218.png （说明：第 1 秒开始 CPU 从 11m ➜ 755m，内存从 1193Mi ➜ 1221Mi）
（说明：CPU 降至 8m，内存仍增长至 1239Mi）
🧠 IAC运行状态
指标 当前值 说明
JVM内存分配 堆：6GB（used：395MB）非堆：1.2GB（used：271MB） 总体内存使用率较低，无内存泄漏迹象
GC情况 ParNew GC：755 次，时间 61sCMS GC：0次 暂未触发 Full GC，长时间未清老年代
类加载数 33,223 正常偏高
线程数 当前 227 个，峰值 232 线程数健康
操作系统 Linux x86_64，单核容器 资源有限
JVM参数 -XX:+UseCMSInitiatingOccupancyOnly-XX:MaxRAMPercentage=75.0 容器内有效限制了 JVM 可用内存上限为 6GB
🔍 详细解读
① 💾 HEAP MEMORY（堆内存）
init: 6GB
used: 395.5MB
committed/max: 6GB
✅ 当前堆使用率为 395MB / 6GB ≈ 6.3%
说明当前并没有内存紧张或泄漏迹象，已经压测过，系统仍旧留有大量空间。
② 💡 NON-HEAP MEMORY（非堆内存）
used: 271.5MB
max: 1.2GB
- 包含 Metaspace、CodeCache 等
- 设置了 -XX:MaxMetaspaceSize=512M，但当前非堆内存已经超过 271MB
- 属于合理区间，未见异常
③ ♻️ GC 情况（垃圾回收）
ParNew: 755 次，61970ms
CMS: 0 次，0ms
CMS（老年代）未被触发！
- 对象大多在新生代就被清理干净
- 批量任务内存增长后并未触发 Full GC
✅ 当前未发现 GC 停顿
④ 🧵 线程情况
Thread Count: 227
Daemon Threads: 103
Peak: 232
Started: 2709
Deadlock: 0
- 当前线程数健康，未发现死锁
- 峰值线程数 < 300，合理
- Started 数较高（可能是线程池不断创建和销毁）
✅ 建议检查线程池是否使用合理，线程是否有回收机制
⑤ 📦 JVM 参数
-XX:InitialRAMPercentage=75.0
-XX:MaxRAMPercentage=75.0
-XX:+UseConcMarkSweepGC
-XX:+DisableExplicitGC
-XX:+HeapDumpOnOutOfMemoryError
✅ 设置了合理的内存百分比参数，符合容器化部署最佳实践
✅ 设置了 OOM dump，可用于分析生产异常
评论