POD发生OOM后的处理策略决策-ADR

[POD发生OOM后的处理策略决策-ADR]

目前运行的java服务发生OutOFmemoryError后POD会卡9分钟才能自行恢复，在这个过程会导致服务整体稳定性影响。运维架构希望这个9分钟能降低到2分钟内。

发生OOM后，服务不会主动停止进程，通过Thread.uncaughtException 机制，监听OOM异常并将异常信息标记到Actuator的liveness健康检查端点。K8s存活探针检查到liveness 500后，触发Pod重启。

配置好JVM参数，发生OOM 触发oom脚本执行，退出当前JVM进程，POD因主进程停止而触发crash重启。

选项

优点

缺点

基于K8s探针触发重启基于K8s探针触发重启

1、优雅重启，先注销nacos；

2、基于liveness探针存活检查；

3、在进程没有卡死的情况，能确保服务基本可用性

1、恢复周期，会经历15秒+启动时间（例：30秒）

2、如果进程卡死状态，恢复周期增加 3次*健康检查超时时间（取决于POD的健康检查配置）

进程卡死，会短周期的（Nacos心跳超时15秒）的部分接口异常；

3、

快速重启

-XX:+ExitOnOutOfMemoryError

1、快速响应故障，杀进程并重启；

2、JVM参数配置简单，不依赖探针；

2、会导致短周期（Nacos心跳超时15秒）的部分接口异常；

3、恢复周期启动时间（例：30秒）

4、规划足够的容量应对单个或多个实例OOM

选择[快速重启]

生产发生OOM大概率是在导出场景这种场景会一直load数据到内存，可能出现服务卡顿加上持续并发接口情况，使用快速杀死进程方式断臂求生，也是快速响应的方式。

当服务触发ExitOnOutOfMemoryError 会有回调脚本触发，回调脚本优先调用shutdown接口来确保nacos注册服务下线，可以将不可用影响降低至1秒级内.

PS：实际验证在30QPS的情况下，2000个请求，发生OOM 会有1-3个请求失败的情况。

1、故障期间一定会产生低于50%的请求15秒时长的不可用，由于请求的命中随机性，可能用户端感受是80%-90%不可用；

2、能够快速响应OOM故障；

3、需要规划足够的冗余服务数量减少影响概率；

分享: 淘江湖新浪 QQ微博 QQ空间开心人人豆瓣网易微博百度鲜果白社会飞信