一个小米SRE的日常问题排查记录

来源 | 公众号：小米运维

日常排查Wed转发服务器负载异常

1. 日常巡检发现新扩容的一台 Web 转发服务器负载异常。比原来的稍高仍然在正常范围内，but 作为一个 SRE 是不能放过任何异常。

2. 安排好其他日常工作开始排查。

（1） 新增服务器系统版本跟原来不一致。（原来为 centos6.x，异常服务器为 centos7.x） ，异常服务器从 lvs 下线重装，保证系统版本都为 6.x 依然没有恢复。（论：保持环境统一重要性。）

为什么要重新装 centos6.x 呢？当时怀疑线上 nginx 是在 centos6.x 环境下编译的，运行在 centos7.x 下面，可能会是这个原因。

（2）仔细对比下环境，确认系统版本 nginx 版本 nginx 配置完全一样。

3. 通过火焰图分析大部分 cpu 占用为 https 握手阶段函数（bn_sqr8x_interna，mul4x_internall），查看 log 发现问题服务器及正常服务器 https 及 http 请求数量相同。（此路不通。）

4. 既然软件环境一样来看硬件及驱动。通过监控确定新增一批服务负载都比原来的稍高, 新增服务器及原来服务器从 cpu，内存硬盘配置一样。确定新增服务器没有节能没开，cpu 内存频率正常硬盘读写正常, 找系统同事查看未见硬件故障。部分驱动版本信息不同，进行了替换验证，整个过程是痛苦的，感谢系统及 dell 同学。（大家一个 team 一起背锅）

5. 通过找不同没有解决问题了。但是我们还是要继续，现在我们很好奇很想知道答案。继续分析我们发现了问题服务器 cpu 很不均衡。为什么不均衡了，strace 一下发现大量的 (Resourcetemporarilyunavailable)cpu 在空转。

来看下 nginx 对请求分配的模型。master 进程监听端口号（例如 80），所有的 nginx worker 进程开始用 epoll_wait 来处理新事件（linux 下），如果不加任何保护，一个新连接来临时，会有多个 worker 进程在 epoll_wait 后被唤醒然后只有一个线程处理这个请求其他的则会失败。cpu 空转负载升高。这就是所谓 epoll_wait 惊群效应。当然 nginx 会有办法处理这个问题：加锁。

6. 剩下的就简单了。对问题服务器手动配置上锁（accept_mutex），然后负载正常了（每把锁都是双刃剑，加不加要具体问题具体分析）。但是，你可能会有疑问版本是一样的啊，正常的服务器也没手动加锁啊。伟大福尔摩斯说过：When you have eliminated the impossibles,whatever remains,however improbable,must be the truth 真相就是线上 nginx 根本不是一个版本（一脸懵逼）。手动查看下线上运行的 nginx 文件被删除了，线上运行了一个不存在的版本，存在的版本是更新了的。原来正常的而服务器上线是 reload 新版 nginx 不会生效，新增的服务器是 start 运行的是新版 nginx。

7. 下面的问题就是 tengine2.1 跟 tengine2.2accept_mutex 参数由默认的 on 改为了 off 为什么要改呢。与时俱进。当初这个参数是为了避免在 epoll_wait 所出现惊群效应。可以参考（https://www.jianshu.com/p/21c3e5b99f4a）新版内核已经有了处理这个方法不再需要 nginx 单独配置。

总结：反思并完善整个运维流程，以避免相关问题再次发生，对 SRE 来说永远是最重要的。

一些启示：

1 线上环境尽量完全一致（容器化可以很好的解决这一点）；

2 每次变更都要谨慎及测试。

---

活动推荐

聚焦高效运维最佳实践，复盘技术大牛的经典与创新案例，从中获取实战经验。QCon 全球软件开发大会广州站，5 月 25-28 日与你相约万富希尔顿。目前，大会 7 折限时优惠，立减 2040 元，团购更多惊喜！扫描下方二维码或点击阅读原文了解，有任何问题欢迎咨询 Joy 同学，电话：13269078023（微信同号）。