成都网站seo诊断,网站建设公司浙江,网站文件夹命名怎么做,城市焦点商城网站建设案例最开始公司运维同学反馈#xff0c;个别宿主机上存在进程CPU峰值使用率异常的现象。而数万台机器中只出现了几例#xff0c;也就是说万分之几的概率。监控产生的些小误差#xff0c;不会造成宕机等严重后果#xff0c;很容易就此被忽略了。但我们考虑到这个异常转瞬即逝、并…最开始公司运维同学反馈个别宿主机上存在进程CPU峰值使用率异常的现象。而数万台机器中只出现了几例也就是说万分之几的概率。监控产生的些小误差不会造成宕机等严重后果很容易就此被忽略了。但我们考虑到这个异常转瞬即逝、并不易被察觉可能还存在更多这样的机器又或者现在正常将来又不正常内核研发本能的好奇心让我们感到此事必有蹊跷于是追查下去。
问题现象
现象一CPU监控非0即100%
该问题现象表现在Redis进程CPU监控的峰值时而100% 时而为0有的甚至是几十分钟都为0突发1秒100%后又变为0如下图。而从大量机器的统计规律看这个现象在2.6.32 内核不存在在4.1内核存在几例。2.6.32是我们较早期采用的版本为平台的稳定发展做了有力支撑4.1 可以满足很多新技术需求如新款CPU、新板卡、RDMA、NVMe和binlog2.0等。后台无缝维护着两个版本并为了能力提升和优化而逐步向4.1及更高版本过渡。
现象二top显示非0即300%
登录到机器上执行top -b -d 1 –p | grep , 可以看到进程的CPU利用率每隔几分钟到几十分钟出现一次300%这意味着该进程3个线程占用的3个CPU都跑满了跟监控程序呈现同样的异常。问题分析
上述异常程序使用的是同样的数据源/proc/pid/stat中进程运行占用的用户态时间utime和内核态时间stime。我们抓取utime和stime更新情况后发现utime或者stime每隔几分钟或者几十分钟才更新更新的步进值达到几百到1000而正常进程看到的是每几秒更新步进值是几十。
定位到异常点后还要找出原因。排除了监控逻辑、IO负载、调用瓶颈等可能后确认是4.1内核的CPU时间统计有 bug。
cputime统计逻辑
检查/proc/pid/stat中utime和stime被更新的代码执行路径在cputime_adjust()发现了一处可疑的地方当utimestime\u0026gt;rtime的时候就直接跳出了也就是不更新utime和stime了这里的rtime是runtime代表进程运行占用的所有CPU时长正常应该等于或近似进程用户态时间内核态时间。 但内核配置了CONFIG_VIRT_CPU_ACCOUNTING_GEN选项这会让utime和stime分别单调增长。而runtime是调度器里统计到的进程真正运行总时长。
内核每次更新/proc/pid/stat的utime和stime的时候都会跟rtime对比。如果utimestime很长一段时间都大于rtime那代码直接goto out了 /proc/pid/stat就不更新了。只有当rtime持续更新追上utimestime后才更新utime和stime。冷补丁和热补丁
第一回合冷补丁
出现问题的代码位置已经找到那就先去内核社区看看有没有成熟补丁可用看一下kernel/sched/cputime.c的 changelog看到一个patch确保stimeutimertime。再看描述像top这样的工具会出现超过100%的利用率之后又一段时间为0这不就是我们遇到的问题吗真是踏破铁鞋无觅处得来全不费工夫patch链接https://lore.kernel.org/patchwork/patch/609410/该补丁在4.3内核及以后版本才提交 却并未提交到4.1稳定版分支于是移植到4.1内核。打上该补丁后进行压测再没出现cputime时而100%时而0%的现象而是0-100%之间平滑波动的值。
至此你可能觉得问题已经解决了。但是问题才解决了一半。而往往“但是”后边才是重点。
第二回合热补丁
给内核代码打上该冷补丁只能解决新增服务器的问题但公司还有数万存量服务器是无法升级内核后重启的。
如果没有其它好选择那存量更新将被迫采用如下的妥协方案监控程序修改统计方式进行规避不再使用utime和stime而是通过runtime来统计进程的执行时间。
虽然该方案快速可行但也有很大的缺点
很多业务部门都要修改统计程序研发成本较高/proc/pid/stat的utime和stime是标准统计方式一些第三方组件并不容易修改并没有根本解决utime和stime不准的问题用户、研发、运维使用ps、top命令时还会产生困惑产生额外的沟通协调成本。
幸好我们还可以依靠UCloud已多次成功应用的技术热补丁技术。
所谓热补丁技术是指在有缺陷的服务器内核或进程正在运行时对已经加载到内存的程序二进制打上补丁使得程序实时在线状态下执行新的正确逻辑。可以简单理解为像关二爷那样不打麻药在清醒状态下刮骨疗伤。当然对内核刮骨疗伤内核是不会痛的但刮不好内核就会直接死给你看没有丝毫犹豫非常干脆利索又耿直。
热补丁修复
而本次热补丁修复存在两个难点
难点一 热补丁制作
这次热补丁在结构体新增了spinlock成员变量那就涉及新成员的内存分配和释放在结构体实例被复制和释放时都要额外的对新成员做处理稍有遗漏可能会造成内存泄漏进而导致宕机这就加大了风险。
再一个就是结构体实例是在进程启动时初始化的对于已经存在的实例如何塞进新的spinlock成员所谓兵来将挡水来土掩我们想到可以在原生补丁使用spinlock成员的代码路径上拦截如果发现实例不含该成员则进行分配、初始化、加锁、释放锁。
要解决问题既要攀登困难的山峰又得控制潜在的风险。团队编写了脚本进行几百万次的加载、卸载热补丁测试并无内存泄漏单机稳定运行再下一城。难点二难以复现
另一个难题是该问题难以复现只有在现网生产环境才有几个case可验证热补丁而又不可以拿用户的环境去冒险。针对这种情况我们已经有标准化处理流程去应对那就是设计完善的灰度策略这也是UCloud内部一直在强调的核心理念和能力。经过分析这个问题可以拆解为验证热补丁稳定性和验证热补丁正确性。于是我们采取了如下灰度策略
稳定性验证先拿几台机器测试正常再拿公司内部500台次级重要的机器打热补丁灰度运行几天正常从而验证了稳定性风险尽在掌控之中。正确性验证找到一台出现问题的机器同时打印utimestime以及rtime根据代码的逻辑当rtime小于utimestime时会执行老逻辑当rtime大于utimestime时会执行新的热补丁逻辑。如下图所示进入热补丁的新逻辑后utimestime打印正常且与rtime保持了同步更新从而验证了热补丁的正确性。全网变更 最后再分批在现网环境机器上打热补丁执行全网变更问题得到根本解决此处要感谢运维同学的全力协助。
总结
综上我们详细介绍了进程cputime统计异常问题的完整分析和解决思路。该问题并非严重的宕机问题但却可能会让用户对监控数据产生困惑误认为可能机器负载太高需要加资源问题的解决会避免产生不必要的开支。此外该问题也会让研发、运维和技术支持的同学们使用top和ps命令时产生困惑。最终我们对问题的本质仔细分析并求证用热补丁的方式妥善的解决了问题。
文章首发于公众号\u0026quot;UCloud技术\u0026quot;: https://mp.weixin.qq.com/s/nIOvQuLtdQwLPi8AqJiBPg
