无人值守的自动 dump（二）

最新推荐文章于 2024-03-19 18:04:22 发布

qcrao

最新推荐文章于 2024-03-19 18:04:22 发布

阅读量244

点赞数

文章标签： python java go redis 多线程

本文链接：https://blog.csdn.net/qcrao/article/details/110211741

版权

之前在这篇无人值守（一）^[1]简单介绍了我们针对线上抖动问题定位的工具的设计思路，思路很简单，技术含量很低，是个人都可以想得到，但是它确实帮我们查到了很多很难定位的问题。

在本篇里，我们重点讲一讲这个工具^[2]在生产环境帮我们发现了哪些问题。

OOM 类问题

RPC decode 未做防御性编程，导致 OOM

应用侧的编解码可能是非官方实现(如 node 之类的无官方 SDK 的项目)，在一些私有协议 decode 工程中会读诸如 list len 之类的字段，如果外部编码实现有问题，发生了字节错位，就可能会读出一个很大的值。

非标准 app ----encode-------> 我们的应用 decode -----> Boom!

decoder 实现都是需要考虑这种情况的，类似这样^[3]。如果对请求方的数据完全信任，碰到对方的 bug 或者恶意攻击，可能导致自己的服务 OOM。

在线上实际发现了一例内存瞬间飚升的 case，收到报警后，我们可以看到：

1: 1330208768 [1: 1330208768] @ 0x11b1df3 0x11b1bcb 0x119664e 0x11b1695 0x1196f77 0x11a956a 0x11a86c7 0x1196724 0x11b1695 0x11b1c29 0x119664e 0x11b1695 0x11b1c29 0x119664e 0x11b1695 0x11b1c29 0x119664e 0x11bb360 0x168f143 0x179c2fc 0x1799b70 0x179acd6 0x1