第一次亲临生产OOM现场

下午，有同事过来反馈说调用统一消息服务异常了，紧接着企业微信也收到若干其他部门同事反馈，调用超时，接着就是服务器告警，剩余内存不足10%。

直接登陆目标服务器，还登毛的堡垒机，我和华子哥一人负责一台服务器，ssh 127.0.0.1登陆服务器。

先看下top，M；内存占用率确实高，坑爹的服务器上面竟有4个java应用进程。其中一个进程占用率已经达到35%，一直高居不下。加上起它三个进程，内存基本90以上了。

使用jmap -heap pid；看下该进程的内存情况，老年代1.2g，基本已经占满了，统一服务都运行n久了，不可能现在才暴露出问题，初步怀疑是某个傻X发大内容消息。

使用jstat -gc pid 1000 10；看下该进程现在的回收情况，full gc一直在勤劳地回收着，应用还跑毛线。

二话不说，我负责查看日志，华子哥把其中一台服务器重启了。日志中到处可见OOM error，gc overhead limit exceeded。基本确定了是STW导致的应用瘫痪，于是我也把服务器重启了。

华子哥tail实时查看日志，刚起的服务突然被满屏的一大串clickhouse相关内容占据。看着费劲，使用sz msg.log；将日志文件下载下来，定位到错误日志，单独把请求拿出来，想直复制到企微群里，可惜内容过大无法粘贴。

粗略计算了下，一条消息内容占用4M空间，一直在发，几百条就能把你搞死。看了下消息模版，立马停用模版，减小伤害。然后找网络拉黑这个傻X的ip地址。

电联该模版使用者，竟然在生产无脑测试。将所谓的clickhouse的一堆错误日志都发了过来。

再次排查日志，发现还有数据库无法get连接异常，数据库表字段限制长度512，4M的数据肯定处理失败。下一步准备合理限制下payload大小。

到这里基本排查完毕了，前后大概15分钟，虽说是亲临生产现场，但也是多见少怪了。

觉得有用点个赞，喜欢请关注：同名公众号【码农小麦】