一开始，公司的操作和维护学生反馈，个别主机上存在CPU CPU使用异常的现象。成千上万的机器中只有少数情况，这意味着数千的概率。监控产生的一些小错误不会导致严重后果，例如停机，很容易忽略这一点。
但我们认为这种异常现象稍纵即逝，不易察觉。可能会有更多这样的机器，或者在正常的未来不正常。内核的研究和发展本能的好奇心让我们觉得这件事一定是有缺陷的！所以追查它。
问题现象
现象1：CPU监控不是0或100％
问题出现在Redis进程的CPU监控峰值，100％为0，有些甚至为0几十分钟，然后在100％爆发1秒后为0，如下所示。
从大量机器的统计规律来看，2.6.32内核中不存在这种现象，4.1内核中有几种情况。 2.6.32是我们早期的版本，它是对平台稳定发展的有力支持。 4.1可以满足许多新技术要求，如新CPU，新板，RDMA，NVMe和binlog2.0。后端无缝地维护两个版本，并逐渐过渡到4.1和更高版本，以进行容量增强和优化。
现象2：顶部显示非零，即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时间统计中存在错误。
Cputime统计逻辑
检查/proc/pid/stat中utime和stime的代码执行路径，并在cputime_adjust（）中找到可疑位置：
当utime + stime>
当=rtime时，它会直接跳出来，也就是说，它不会更新utime和stime！这里的rtime是运行时，它表示正在运行的进程占用的所有CPU的长度。通常它应该等于或接近进程用户状态时间+内核状态时间。但是内核配置了CONFIG_VIRT_CPU_ACCOUNTING_GEN选项，这会导致utime和stime单调增长。运行时是调度程序中计算的进程的总运行时间。每次内核更新/proc/pid/stat的utime和stime时，它都将与rtime进行比较。如果utime + stime长时间比rtime长，代码会直接输出，而/proc/pid/stat不会更新。只有当rtime不断更新并赶上utime + stime时，utime和stime才会更新。
冷补丁和热补丁
第1轮：冷补丁
如果找到了发生问题的代码位置，则转到内核社区以查看是否有可用的成熟补丁。看一下kernel/sched/cputime.c的更新日志并查看补丁：确保stime + utime=rtime。看看描述：像top这样的工具会有超过100％的利用率，然后0一段时间，是不是我们遇到的问题？这真的是一个突破铁鞋的无辜地方，这一切都值得努力！ （补丁链接：https://lore.kernel.org/patchwork/patch/609410/）
补丁是在4.3内核中提交的，后来却没有提交到4.1 stable分支，所以它被移植到4.1内核。在应用贴片之后，进行压力测量，并且没有100％然后0％的cputime现象，而是0-100％之间的平滑波动的值。
此时，您可能会觉得问题已经解决了。然而，问题解决了一半。通常“但”是背后的焦点。
第二轮：热补丁
将此冷补丁应用于内核代码只能解决添加新服务器的问题，但该公司仍有成千上万的库存服务器，在内核升级后无法升级。
如果没有其他好的选择，那么库存更新将被迫采用以下折衷方案：监控程序修改统计信息以避免使用运行时来计算进程的执行时间，而不是使用utime和stime。
虽然该程序快速可行，但它也有一个主要缺点：
1.许多业务部门必须修改统计程序，研发成本高；
2./proc/pid/stat的utime和stime是标准统计方法，有些第三方组件不易修改；
对于不准确的utime和stime问题没有根本的解决方案。使用ps和top命令时，用户，研发，操作和维护也会混淆，从而导致额外的通信和协调成本。
幸运的是，我们还可以依靠UCloud的许多成功应用：热补丁技术。
所谓的热补丁技术意味着当有缺陷的服务器内核或进程正在运行时，已经加载到内存中的程序二进制文件被修补，以便程序在实时在线状态下执行新的正确逻辑。可以简单地理解，如果你不使用Guan Erye这样的麻醉，你可以治疗处于清醒状态的骨骼。当然，治愈核心核心并不痛苦，但如果你不抓内核，你将直接死于你。毫不犹豫，这是非常直截了当的。热补丁修复
这个热补丁修复有两个困难：
难点1：热补丁生产
此热补丁将spinlock成员变量添加到结构中，这涉及内存分配和新成员的释放。复制和释放结构实例时，必须处理其他成员。可能会略有遗漏。这会造成内存泄漏的风险，从而导致停机。
另一个是在进程启动时初始化struct实例，以及如何为现有实例插入新的spinlock成员？所谓的士兵会阻挡水覆盖地面，我们认为你可以使用自旋锁成员截取本机补丁的代码路径，如果发现实例不包含该成员，则分配，初始化，锁定，释放锁。
要解决这个问题，有必要攀登困难的高峰并控制潜在的风险。该团队编写脚本以加载数百万次，卸载热补丁测试，无内存泄漏，单台机器的稳定运行，然后是另一个城市。
困难二：难以重现
另一个困难是问题很难再现。只有在实时生产环境中才能有几种情况来验证热补丁，而不是让用户的环境承担风险。针对这种情况，我们有一个标准化的流程来处理，即设计一个完整的灰色策略，这是UCloud一直强调的核心概念和能力。分析后，可以分解此问题以验证热补丁稳定性并验证热补丁的正确性。所以我们采用了以下灰度策略：
1.稳定性验证：首先拿几台机器进行正常测试，然后拿公司内部500台重要的二次机进行热补丁，灰度运行几天正常，从而验证稳定性，风险得到控制。
2.正确性验证：找到有问题的机器，同时打印utime + stime和rtime。根据代码的逻辑，当rtime小于utime + stime时，将执行旧逻辑。当rtime大于utime + stime时，将执行new。热补丁逻辑。如下图所示，在输入热补丁的新逻辑后，utime + stime正常打印并继续使用rtime进行更新，从而验证热补丁的正确性。
3.整个网络的变化：最后，在批处理中，在现有的网络环境机器上进行热补丁，实现整个网络的变化。问题从根本上解决了。感谢操作和维护学生的全力协助。
总结一下
总之，我们详细介绍了流程cputime统计异常问题的完整分析和解决方案。此问题不是严重的停机问题，但可能会导致用户对监控数据感到困惑。如果您认为机器负载过高，则需要添加资源。问题将得到解决，以避免不必要的开支。此外，使用top和ps命令，这个问题也会给学生在研发，操作和技术支持方面造成混淆。最后，我们仔细分析并验证了问题的本质，并通过热补丁正确解决了问题。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: Apple新推出的MacBook Pro有望改变什么？

• 分享到：