上线新功能后,要多观察。如果出现不稳定性的情况,需要高优先级查清原因,避免出现更大的问题。
部分应用出现重启
服务不稳定状态时堆内存及GC情况
出现占用大内存的操作,导致FullGC频繁。
不是。看查询报错的请求低于12%
ots的报错情况
Full GC耗时过长,导致容器判定pod异常,并将其重启。
异常期间,pod存活探测的规则如下:
livenessProbe: # 存活探测的相关配置如下
httpGet:
path: /ready
port: http
initialDelaySeconds: 180
periodSeconds: 10 # 每隔10s探测一次
timeoutSeconds: 1 # 如果/ready接口1s内没有返回,则判断失败
successThreshold: 1
failureThreshold: 3 # 连续失败3次,则判断pod异常。容器重启pod
FullGC时会STW,此时所有请求都会阻塞。
FullGC耗时超过30s,pod就会重启。异常期间FullGC耗时都超过120s了。按配置的规则,容器会重启该pod
FullGC超过30s,则容器会将pod重启
出现了耗内存的操作。
TableStore服务器返回的数据,占用大量内存
新加的查询TableStore的业务线程
不合理。从业务上看,每次查询符合条件的记录最多不会超过100条。但现在返回了131262条
返回的数据量过多
核对过代码,发现查询条件错误。查询tableStore的三个条件应该是and的关系,但现在是or
存在错误逻辑是2020年上线的老代码。写新功能的同学,直接copy过去。想着是两年前的线上代码,code reivew就没有作为重点,具体过程,相关的同学都不记得了。
之前的服务也是有问题的。
老代码由一个定时任务触发。只是串行查询TableStore,虽然会耗内存,但如果正在执行的pod没有其它在执行的耗内存操作,是不会触发FullGC的。
这也可能是当前应用偶发出现重启的原因。
新业务场景是接收到mq消息然后根据条件去触发这段老代码,当同时接收n个消息,则占用的内存*n ,则很容易触发FullGC
在查询TableStore,需要满足条件才会触发有异常的老代码。异常时,触发异常逻辑的的业务数据较多。
case没有全部覆盖业务场景。
当三个and的筛选条件被错写成or,查到的数据会变多。
目前的这个场景所涉及到的查询结果数据,被用于数据权限控制,返回的数据变多时造成的问题是,该看到该数据的人可以看到,不该看到该数据的也可以看到。
如果测试case只有一个:该查看数据的人是否可以查看。那么,测试是通过的。
如果pod重启时,是qps增高,则优先增加Pod
如果pod重启时,识别到FullGC耗时过长,则优先考虑增加内存来解决
出现异常时,要把jvm堆内的数据dump出来。在没有找到异常原因时,要把dump出来的堆数据都查看一下,因为dump时,有的pod中的jvm可能刚启动不久,异常操作还没有被触发。
已经在线的代码,如果新功能涉及到,尽量不要copy
已经在线的代码,如果新功能涉及到,也要CodeReview
待上线的代码,要测试充分
待上线的功能,关键路径,测试Case要全面
增加jvm堆内存的告警,如果超过80%时就告警,然后dump出Heap内的数据进行分析
每个迭代确保用于技术优化的时间。目前这部分有一个bug需要解决:当前的规则中,需求的优先级是由产品决定,一个技术需求如果产品把优先级降低,如果引发故障,产品却不需要承担责任。需要推动这个事情解决,保持权责利一致,做多大的决定,就需要负多大的责任,也享受多大的利好。
FullGC耗时过长的原因及解决办法
相关阅读: