案例九：9月16日通用定点应用访问报错：服务器维护升级中

一、 故障简述

故障简要描述：9月16日早上09:30开始，通用定点应用访问报错：服务器升级中，重启应用后，再次出现应用访问报错，两次不可用时间共计21分钟

网上服务市场大厅界面

联系单列表界面500

联系单创建界面

二、 故障处理过程

09:22 监控告警群告警：web-fixed-universal: Appservice is down,应用jvm的fullGC次数过多
09:29 凌秋反馈开发起点排查原因
09:30 客满小猫开始接到用户反馈，通用定点应用访问报错：系统生病了，程序员GG正在抢救。联系单页面报错：很抱歉，服务器维护升级中。
09:31 监控告警群告警：实例cpu使用率高
09:32 监控告警群再次告警：web-fixed-universal: Appservice is down，应用jvm的fullGC次数过多
09:33 起点开始定位排查，并在线上故障快速处理群反馈。
09:34 起点未定位到具体原因，开始操作重启应用。
09:40 应用恢复，访问正常
09:52 由于未查到故障根本原因，应用再次无法访问。
09:53 告警群告警：app web-fixed-universal dubbo接口延时过高
09:54 客满再次反馈应用访问报错。
09:55 起点开始再次操作重启应用。
10:05 应用恢复正常可以正常访问。
10:10 若谷排查反馈：应用GC时间很长
10:18 若谷操作升级应用JVM内存由2G到4G
起点，青云，阿四，若谷，徐四一起协作排查定位原因，等待晚上下班后再dump
起点于16日晚操作dump数据，尝试复现该问题，未复现。
起点于17日晚排查定位到问题原因。

三、 影响产品线及影响面

通用定点业务线的所有用户

四、 故障原因

应用jvm内存较小，参数设置不合理，且使用的是parallel gc垃圾回收机制，之前设置的内存为2G，启动参数没有设置young区和old区的大小，young区和old区比例约为1:2，但是suvivor区的大小约为10M，在进行young gc时，如果存活对象的大小超过5M，会直接进入老年代，导致老年代越来越大，必须进行fullgc才能释放内存，young gc的效果已经不太明显。

平时对pinpoint关注较少，其实这个问题之前发生过，但是时间是在晚上，如下图，9月12号晚上19:17和20:07两次fullgc的时间分别达到92秒和30秒，因为此时访问的用户较少，所以没有导致流程阻塞，9月16号早上访问的用户较多，此时fullgc会阻塞线程，导致挂起的线程越来越多，cpu占用也越来越高，因为fullgc也需要占用大量的cpu时间，进入恶性循环，最终导致服务挂起

9月12日的监控数据：

cn.gov.zcy.fixed.center.service.admin.impl.PurchasePlanReadServiceImpl#pagingPlans有循环调用采购目录的dubbo接口，从pinpoint数据可以看出该接口的平均调用时间基本都在10秒以上，这个问题不是导致此次事故的原因

五、 故障评级
故障等级：P2
故障类别：程序问题

六、 后续ACTION：

改进措施

增加jvm内存，由2G升级到4G，9月16号上午11点若谷已执行

修改jvm默认参数，修改后的参数如下

目前的参数设置基本能满足线上需求，同时需要持续关注pinpoint和监控大盘中内存使用情况来逐步优化

1.采购业务全线JVM性能优化 起点 9月30日

2.排查循环调用 青松 9月30日 （依赖中台，需要提供批量接口）

3.前台大厅 屏蔽未知异常 起点 10月15日

4. dump时候，不要触发FULLGC ，platform，片风 9月30日（自动dump堆栈信息，发送链接，待定）

5.运维保护现场，切换流量，重启，待定