软件开发架构师

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

运维 45 2019-02-28 15:30
来源 | 公众号:小米运维
日常排查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(微信同号)。

文章评论