内容简介:(1)新增服务器系统版本跟原来不一致。(原来为centos6.x,异常服务器为centos7.x) ,异常服务器从lvs下线重装,保证系统版本都为6.x依然没有恢复。(论:保持环境统一重要性。)为什么要重新装centos6.x呢?当时怀疑线上nginx是在centos6.x环境下编译的,运行在centos7.x下面,可能会是这个原因。(2)仔细对比下环境,确认系统版本nginx版本nginx配置完全一样。
本文主要介绍了SRE的日常工作及存在的各方面问题。
上篇文章回顾:TiDB应用实践
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)每次变更都要谨慎及测试
本文首发于公众号”小米运维“,点击查看原文。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。