本文主要介绍了小米SRE的日常工作及遇到的各方面问题和处理方法，值得借鉴。1、日常巡检发现新扩容的一台Web转发服务器负载异常。比原来的稍高但仍然在正常范围内，but作为一个SRE是不能放过任何异常。
2、安排好其他日常工作开始排查。
新增服务器系统版本跟原来不一致。（原来为CentOS 6.x，异常服务器为CentOS 7.x） ，异常服务器从LVS下线重装，保证系统版本都为6.x依然没有恢复。（论：保持环境统一重要性。）
为什么要重新装CentOS 6.x呢？当时怀疑线上Nginx是在CentOS 6.x环境下编译的，运行在CentOS 7.x下面，可能会是这个原因。
仔细对比下环境，确认系统中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出现惊群效应，可以参考：p/21c3e5b99f4a。新版内核已经有了处理这个的方法，不再需要Nginx单独配置。
总结：反思并完善整个运维流程，以避免相关问题再次发生，对SRE来说永远是最重要的。
一些启示：
|
转播
分享
淘帖
()