2022几次线上问题的记录

1. MetaSpace 容量临界导致的OOM和GC

问题表征

在某个节日来临之前的高峰期线上某服务突然频发fullGC，重启和新增实例后无明显改善

解决方法

经排查是metaspace设置的128m，已经临界并 达到上限 频繁GC也无法回收导致，查看GC日志看到是MetaSpace空间不足，对MetaSpace进行扩容之后问题得到解决

2. 更换部署方式后GC时间增加

问题表征

配合运维侧变更，服务的部署方式从虚拟机部署改为docker部署，多个中间件读物到的 cpu核数从虚拟 机核数改为读取容器宿主机的核数， 48核，96线程。
因为在高版本的Java可以正确读取，单是该版本是商业版本无法升级。

2019 年 1 月份之后，Oracle Java 8 的公开更新将不向没有商用许可证的业务、商用或生产用途提供。
因为 Oracle JDK 8 u191 是 2019 年 1 月前发布的最新版本，所以只要一直使用 JDK 8 u191 以及更早的版本，就不需付费。
JDK 8 u201 和 JDK 8 u202 仍可免费使用。

解决方法：

1. 通过增加启动参数，限制JVM的 YongGC和Full GC的线城市，和容器分配的核心数接近。
2. 研究各个中间件的源码后增加相关配置，skywalking、nacos、rocketMQ、ES
   结果从500+线程，降低到300+线程

3. 业务错配导致频繁FullGC

问题表征

某个奖品，单人发放数量设置了百万级别，导致生成发放使用产生了影响。
该业务上线一周后，运营才开始正式配置。

副作用

1. Redis MGET，因为前置ID未做去重处理，导致MGET时间超长
2. 单用户获取可用资产，数据量过大超时

解决方法：

1. 对发送上游业务进行降级，停用。
2. 对发放资产进行统计
3. 对已发放资产进行数据回收。
4. 对相关运营系统增加兜底校验

4. 二方服务升级Bug导致频繁GC

表征

某服务GC陡增，通过dump 堆内存和接口调用日志后，定位到是某二方服务查询接口分页参数失效，导致死循环，进而一直有数据。

解决方法：

1. 及时通知对方。
2. 对该接口紧急降级
3. 对该接口增加严格校验

5. 修改配置后业务无法报出

问题表征

协助运营修改部分线上运营规则后，无异常无报警，但是某业务确受影响了

解决方法

1. 进行恢复数据修复
2. 增加业务监控及报警
3. 增加该业务场景下的兜底业务规则，避免认为错误。

总结

1. 监控优先，要建立完备的监控和报警体系。
2. 业务开发要有降级能力，在遇到突发情况时可以低成本且快速的进行业务降级。
3. 多观察监控，多进行巡检，主动发现非正常的趋势。