181 lines
5.3 KiB
Markdown
181 lines
5.3 KiB
Markdown
# 内存使用率过高告警处理方案
|
||
|
||
## 告警名称
|
||
- **告警名**: `HighMemoryUsage`
|
||
- **告警级别**: 严重
|
||
- **触发条件**: 内存使用率持续5分钟超过85%
|
||
|
||
## 问题描述
|
||
当服务器或容器的内存使用率持续超过85%时，可能导致：
|
||
- 应用频繁GC（垃圾回收）
|
||
- OOM（Out Of Memory）错误
|
||
- 应用崩溃或重启
|
||
- 系统swap频繁，性能急剧下降
|
||
|
||
## 排查步骤
|
||
|
||
### 步骤1: 获取当前时间
|
||
**工具**: `get_current_time`
|
||
**目的**: 确定告警发生的时间范围
|
||
|
||
### 步骤2: 查询系统监控日志
|
||
**工具**: `query_logs`
|
||
**参数要求**:
|
||
- **地域**: `ap-guangzhou`
|
||
- **日志主题**: `system-metrics`
|
||
- **时间范围**: 最近30分钟
|
||
- **查询条件**: `memory_usage:>85 OR event:OOM`
|
||
|
||
**查询示例**:
|
||
```
|
||
地域: ap-guangzhou
|
||
日志主题: system-metrics
|
||
时间范围: [当前时间-30分钟] 到 [当前时间]
|
||
查询语句: memory_usage > 85 OR oom_kill:true
|
||
```
|
||
|
||
### 步骤3: 查询应用日志
|
||
**工具**: `query_logs`
|
||
**参数要求**:
|
||
- **地域**: `ap-guangzhou`
|
||
- **日志主题**: `application-logs`
|
||
- **查询条件**: `OutOfMemoryError OR GC overhead`
|
||
|
||
### 步骤4: 分析内存使用情况
|
||
从日志中提取：
|
||
- JVM堆内存使用情况
|
||
- GC频率和耗时
|
||
- 是否有内存泄漏迹象
|
||
- 大对象分配记录
|
||
|
||
## 常见原因分析
|
||
|
||
### 原因1: 内存泄漏
|
||
**特征**:
|
||
- 内存使用率持续缓慢上升
|
||
- Full GC后内存无法释放
|
||
- 应用运行时间越长，内存占用越高
|
||
- 日志中有大量GC记录
|
||
|
||
**处理方案**:
|
||
1. **紧急措施**: 重启应用释放内存
|
||
2. **获取堆转储**: 在重启前dump内存快照
|
||
3. **分析内存泄漏**: 使用MAT工具分析堆转储文件
|
||
4. **定位代码问题**: 找出持有大量对象引用的代码
|
||
5. **修复并发布**: 修复内存泄漏代码并重新部署
|
||
|
||
### 原因2: 流量突增导致对象激增
|
||
**特征**:
|
||
- 内存使用率突然升高
|
||
- 与流量增长同步
|
||
- GC能够回收大部分内存
|
||
- 应用日志显示请求量激增
|
||
|
||
**处理方案**:
|
||
1. **立即扩容**: 增加应用实例数量
|
||
2. **启用限流**: 保护系统不被压垮
|
||
3. **优化缓存**: 检查缓存策略是否合理
|
||
4. **增加内存**: 如果是合理的业务增长，考虑增加内存配置
|
||
|
||
### 原因3: 缓存配置不当
|
||
**特征**:
|
||
- 缓存占用内存过大
|
||
- 缓存命中率低
|
||
- 缓存数据长时间不过期
|
||
- 日志中有缓存相关警告
|
||
|
||
**处理方案**:
|
||
1. **调整缓存大小**: 减少缓存容量上限
|
||
2. **优化过期策略**: 设置合理的TTL
|
||
3. **启用LRU淘汰**: 确保缓存能自动淘汰旧数据
|
||
4. **监控缓存指标**: 持续观察缓存命中率和内存占用
|
||
|
||
### 原因4: 大文件或大数据处理
|
||
**特征**:
|
||
- 特定时间点内存突增
|
||
- 日志中有文件上传或数据导入记录
|
||
- 处理完成后内存可以释放
|
||
- 与定时任务或用户操作相关
|
||
|
||
**处理方案**:
|
||
1. **优化处理逻辑**: 改为流式处理，避免一次性加载
|
||
2. **限制文件大小**: 设置上传文件大小限制
|
||
3. **分批处理**: 大数据处理改为分批次进行
|
||
4. **异步处理**: 将大数据处理任务放到后台队列
|
||
|
||
### 原因5: JVM参数配置不合理
|
||
**特征**:
|
||
- 堆内存配置过小
|
||
- 新生代和老年代比例不合理
|
||
- GC算法选择不当
|
||
- 元空间（Metaspace）溢出
|
||
|
||
**处理方案**:
|
||
1. **调整堆内存**: 增加-Xmx和-Xms参数
|
||
2. **优化GC参数**: 根据应用特点选择合适的GC算法
|
||
3. **调整代际比例**: 优化-XX:NewRatio参数
|
||
4. **增加元空间**: 调整-XX:MetaspaceSize参数
|
||
|
||
## 紧急处理措施
|
||
|
||
### 立即操作（5分钟内）
|
||
1. **重启高内存实例**: 快速释放内存，恢复服务
|
||
2. **扩容**: 增加实例数量，分散内存压力
|
||
3. **限流**: 如果是流量问题，启用限流保护
|
||
|
||
### 短期措施（30分钟内）
|
||
1. **分析日志**: 确定内存增长的根本原因
|
||
2. **dump内存快照**: 保留现场用于后续分析
|
||
3. **调整JVM参数**: 如果是配置问题，临时调整参数
|
||
4. **清理缓存**: 手动清理不必要的缓存数据
|
||
|
||
### 长期优化
|
||
1. **代码优化**: 修复内存泄漏，优化对象创建
|
||
2. **监控完善**: 增加内存监控指标和告警
|
||
3. **压力测试**: 定期进行内存压力测试
|
||
4. **容量规划**: 根据业务增长合理规划内存容量
|
||
|
||
## 验证步骤
|
||
1. 确认内存使用率降到正常水平（<70%）
|
||
2. 观察GC频率和耗时是否正常
|
||
3. 检查应用日志无OOM错误
|
||
4. 持续监控30分钟确保稳定
|
||
|
||
## 预防措施
|
||
1. **设置合理的内存告警阈值**: 70%预警，85%严重
|
||
2. **定期内存分析**: 每周分析内存使用趋势
|
||
3. **代码审查**: 关注大对象创建和集合使用
|
||
4. **压力测试**: 上线前进行充分的内存压力测试
|
||
|
||
## 相关工具命令
|
||
|
||
### 查看JVM内存使用
|
||
```bash
|
||
jmap -heap <pid>
|
||
```
|
||
|
||
### 生成堆转储文件
|
||
```bash
|
||
jmap -dump:format=b,file=heap.hprof <pid>
|
||
```
|
||
|
||
### 查看GC日志
|
||
```bash
|
||
jstat -gc <pid> 1000
|
||
```
|
||
|
||
## 相关告警
|
||
- `HighCPUUsage`: CPU使用率过高（可能伴随频繁GC）
|
||
- `FrequentGC`: GC频率过高
|
||
- `OOMError`: 内存溢出错误
|
||
- `SlowResponse`: 响应时间过长
|
||
|
||
## 联系方式
|
||
- **运维团队**: ops-team@company.com
|
||
- **开发团队**: dev-team@company.com
|
||
- **紧急电话**: 400-xxx-xxxx
|
||
|
||
## 参考文档
|
||
- [JVM内存管理最佳实践](internal-docs/jvm-memory-best-practices.md)
|
||
- [内存泄漏排查指南](internal-docs/memory-leak-troubleshooting.md)
|