01「假话」10分钟内调优CPU利用率大多数开发者在面试的时候都会被面试官问到一个问题：“请举一个在之前的工作过程中你认为自己做得很好的例子”。换句话说：“请吹牛。”对于普通人来说，他会花时间吹嘘这个废话。大部分符合“28法则”，真实8分，美化2分。然而，一位不愿透露姓名的初级开发同学曾大胆地说：我只需要10分钟就可以快速调优生产环境机器的CPU利用率。”02同学，请说明一下，我的前雇主是从事社交电商，猪会飞，但是我们系统架构的性能太弱了，养不起这只猪。.看个买家秀，翻页.......老大下了死命令，两周内所有主流程接口的RT（接口响应时间）必须优化到200ms以内！扣多少KPI由超出的ms数。同学们，不要展开太多，说重点，回到CPU利用率调优！！！哦哦哦，我要先搞清楚这个问题的背景：应用我们负责的都有一个接口，逻辑很简单，主要是数据计算一般需要130ms左右，但总是时不时超过200ms。应用所在机器内存、网络、磁盘等资源正常，CPU占用50%左右，并发不高。同事查了一天，代码的计算逻辑已经优化到了极致，但是问题还是没有解决。03这波操作，秀！同样的请求，同样的逻辑，稳定的资源，为什么有时耗时长，有时又正常？解决问题的关键是找出请求执行的不同点。我使用Kindling程序相机捕获了正常和异常请求。Normal-below200ms:Abnormal-above200ms:可以很明显的看到，超过200ms的requests需要大量的时间去做其他的事件（就是CPUrunqueue，kindling开源团队还在调整中，这个词会以后使用清楚显示）。《什么是CPUrunqueue？什么情况下程序CPUrunqueue会耗时很长？这其实就是我们大学课程计算机原理中的基础知识：CPUrunqueue是一个概念，就是等待CPU时间的意思，它是一个主动队列一个系统，用于存放正在等待CPU资源的进程，当一个进程请求CPU资源时，会被加入runqueue，等待CPU分配时间片。当一个CPU时间片被分配给一个进程时，该进程就会从运行队列中移除。引用的运行队列时间是指进程在运行队列中等待CPU时间的时间长度。如果runqueue时间过长，说明CPU资源紧张，不能及时处理所有请求。》参考另外，可以切换到Kindling程序相机中耗时200ms以上的复杂视图：继续滑动查看更多线程：可以看到有上百个线程并发执行任务（查看代码后发现，确认这是一个开发在application中写的Timingtasks)，这意味着CPUrunqueue中有很多任务在排队，虽然本机CPU使用率在50%左右，看起来不高，但是并发越多threads，CPU调度越慢。因此，如果有一些请求在排队，执行起来就会越慢可以优化线程，降低CPU开销。或者调整进程优先级，控制CPU资源的分配04最后说点正经的，CPU使用率过低，意味着CPU没有得到合理利用，造成资源浪费；太高会影响系统的性能。大多数操作和维护都是基于经验。确定CPU的最高阈值，但不同的业务场景对CPU利用率的要求不同。大家都知道CPU用满到100%肯定会让应用崩溃，而80%对性能有多大影响呢？?40%靠谱吗？该指标不能用作衡量应用程序性能的指标。归根结底，CPU运行队列时间是衡量的关键。我们需要根据实际情况进行调整。而Kindling程序摄像头是一个非常好的工具，就像上面提到的案例，我们可以通过它“看到”程序在不同CPU资源下的实际执行情况，快速找到调优方向。05附录-Kindling程序摄像头技术介绍Kindling程序摄像头精准还原程序执行场景能力帮助我们：故障排查：分钟级定位各类资源故障根因调优：直观展示资源配置对程序执行的影响**Kindling基于eBPF技术集成了Tracing、Logging和Metrics。也就是说，它收集了接口执行那一刻的所有数据：网络、磁盘、内存等性能指标mysql、redis等网络请求连接信息和消息信息、日志、堆栈、锁信息和文件IO信息....（欢迎尝试，发现Kindling的能力更多）被筛选出来附加到对应的线程事件上，准确还原程序执行的场景。07附录-更多关于Kindling的知识想知道它的实现原理可以参考下面链接：eBPF程序camera-努力解决未来可观测性领域最有价值和最具挑战性的问题更多Kindling程序的使用camera生产环境快速排障案例请查看：10分钟黄金期排障案例合集Kindling是一个开源项目，开源之路任重而道远。希望大家能给本文点个赞，一键三连，多多支持，谢谢~有问题可以加小编wx：xieyun-kindlingKindling官网GitHub
