请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 292|回复: 0

小米SRE每天都在干啥了?

[复制链接]
发表于 2020-12-9 11:16:31 | 显示全部楼层 |阅读模式

! N& l0 G2 t) ~2 o; w4 L; l本文主要介绍了小米SRE的日常工作及遇到的各方面问题和处理方法,值得借鉴。1、日常巡检发现新扩容的一台Web转发服务器负载异常。比原来的稍高但仍然在正常范围内,but作为一个SRE是不能放过任何异常。
8 Q9 o0 y, D) ~1 H+ D 1.png ( J: V* |$ i  f$ v1 r+ T8 f( {
2、安排好其他日常工作开始排查。& d1 g* {" h% `( j( M! l
新增服务器系统版本跟原来不一致。(原来为CentOS 6.x,异常服务器为CentOS 7.x) ,异常服务器从LVS下线重装,保证系统版本都为6.x依然没有恢复。(论:保持环境统一重要性。)& S, ]& _: s8 N3 g$ C# X+ z* A/ p
为什么要重新装CentOS 6.x呢?当时怀疑线上Nginx是在CentOS 6.x环境下编译的,运行在CentOS 7.x下面,可能会是这个原因。
# l3 q9 o( m7 X" L# B4 M" w仔细对比下环境,确认系统中Nginx版本Nginx配置完全一样。9 j0 g5 d. h! h  F/ E* t
2.png
+ ~2 I- a% R$ f8 E, V' R; L3、通过火焰图分析大部分CPU占用为https握手阶段函数(bn_sqr8x_interna,mul4x_internall),查看log发现问题服务器及正常服务器https及http请求数量相同。(此路不通)* f: H: C# [4 M+ S( W; l% a' g
3.png
* f( C4 l1 `+ i" f/ n
4、既然软件环境一样,来看硬件及驱动。通过监控确定新增一批服务负载都比原来的稍高,新增服务器及原来服务器CPU,内存硬盘配置一样。确定新增服务器没有,节能没开,CPU内存频率正常,硬盘读写正常,找系统同事查看未见硬件故障。部分驱动版本信息不同,进行了替换验证,整个过程是痛苦的,感谢系统及dell的同学。(大家一个team一起背锅)% z1 K% s& W& X& v+ P3 h. u
4.png 5.png   B2 _+ W% n4 B6 b( s; }
5、通过找不同,没有解决了问题。但是我们还是要继续,现在我们很好奇很想知道答案。继续分析,我们发现了问题,服务器CPU很不均衡。为什么不均衡呢,strace一下发现大量的(Resourcetemporarilyunavailable)CPU在空转。) o8 }) h2 x* w, S9 d3 r
来看下Nginx对请求分配的模型。Master进程监听端口号(例如80),所有的nginx worker进程开始用epoll_wait来处理新事件(Linux下),如果不加任何保护,当一个新连接来临时,会有多个worker进程在epoll_wait后被唤醒,然后只有一个线程处理这个请求,其他的则会失败,CPU空转负载升高。这就是所谓的epoll_wait惊群效应。当然Nginx会有办法处理这个问题:加锁。) e7 @8 x/ y) h$ ?
6.png 6 m1 @# H+ p# v
6、剩下的就简单了。对问题服务器手动配置上锁(accept_mutex),然后负载正常了(每把锁都是双刃剑,加不加要具体问题具体分析)。但是,你可能会有疑问,版本是一样的啊,正常的服务器也没手动加锁啊。伟大的福尔摩斯说过:“When you have eliminated the impossibles,whatever remains,however improbable,must be the truth.”真相就是线上Nginx根本不是一个版本(一脸懵逼)。手动查看,发现线上运行的Nginx文件被删除了,线上运行了一个不存在的版本,存在的版本是更新了的。原来正常的服务器上线是reload新版Nginx,不会生效,新增的服务器是start运行的新版Nginx。
& y& C) _+ j% Y3 k" f 7.png
4 K+ q9 ~* D2 j0 v9 e4 w' j7、下面的问题就是tengine2.1跟tengine2.2accept_mutex参数由默认的on改为了off,为什么要改呢?与时俱进,当初这个参数是为了避免在epoll_wait出现惊群效应,可以参考:https://www.jianshu.com/p/21c3e5b99f4a。新版内核已经有了处理这个的方法,不再需要Nginx单独配置。
- F5 i* j# L- K# k; ~总结:反思并完善整个运维流程,以避免相关问题再次发生,对SRE来说永远是最重要的。
& _& B! ~( r: h1 }' }7 n! R3 Y  i一些启示:
4 b- W2 b$ p8 \# T2 k0 S& X! ~
  • 线上环境尽量完全一致(容器化可以很好的解决这一点);
  • 每次变更都要谨慎及测试。
    2 i+ d: o) B  j" Y

+ K+ Z. O* `2 p7 P* @% [$ c5 G




上一篇:在容器时代下DevOps与SRE是如何发展与变化的
下一篇:在SRE的位置上如何看待推荐和搜索

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-25 09:32 , Processed in 0.162225 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表