首页 > 其他分享 >如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法

时间:2023-02-09 10:31:32浏览次数:59  
标签:10 Kindling runqueue 调优 200ms 服务器 CPU 摄像头


 01 “妄言”10分钟内调优CPU利用率

绝大部分开发在面试时都会被面试官问到一个问题:“请举一个在以前工作过程中你觉得自己做的非常不错的事例”

换言之:“请吹一个牛”

一般人呢,这个牛他会悠着点吹,大多数符合“28定律”,8分实话2分润色

但是有一位不愿透露姓名的初级开发同学曾大言不惭的说:

“我只要10分钟就能快速调优生产环境机器的CPU利用率”

02 同学,请你展开说说

我的前东家是做社交电商的,前两年正是社交电商的风口,碰上风口猪都能飞,但是我们系统架构性能都太弱了,撑不起这头猪。比如用户经常会遇到:

  • 查个商品,页面转啊转......
  • 下个单,页面转啊转......
  • 看个买家秀,页面转啊转......

老板就下了死命令,两周内所有主流程接口的RT(接口响应时间)必须优化到200ms以内!超出多少ms扣多少KPI。

同学,你不要展得太开了,说重点,回到CPU利用率调优上来!!!

哦哦哦,我需要先把这个问题背景交代清楚:

  • 我们负责的应用有个接口,逻辑很简单,主要是数据计算
  • 正常耗时一般都在130ms左右
  • 但它总时不时的飚到200ms以上
  • 应用所在机器的内存、网络、磁盘等资源都正常,CPU在50%左右
  • 并发量不高

同事查了一天,代码的计算逻辑已经优化到极致,问题依然没有解决。

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_调优

03 这一波操作,秀!

同一个请求、同一个逻辑,资源稳定,为什么有时候耗时高有时候正常?

解决问题的关键就是找出请求在执行过程中的不同之处。

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_ebpf_02

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_java_03编辑

我用Kindling程序摄像头分别捕捉了正常和异常两种情况下的请求。

1. 正常-200ms以下:

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_运维_04

2. 异常-200ms以上:

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_ebpf_05

可以清楚的看到,耗时200ms以上的请求,耗费了大量的时间在做other事件

(即CPU runqueue,kindling开源团队目前还在调整,后续会将这个名词明确展示)。


啥是CPU runqueue?什么情况下会导致程序CPU runqueue时间长?

这其实是我们大学课程计算机原理里的基础知识:

CPU runqueue 是一个表示等待 CPU 时间的概念。它是一个系统的活动队列,用于存储正在等待 CPU 资源的进程。


当一个进程请求 CPU 资源时,它会被添加到 runqueue,等待 CPU 分配时间片。当 CPU 时间片分配给进程时,该进程会从 runqueue 中移除。


runqueue 时间是指进程在 runqueue 中等待 CPU 时间的长度。

如果 runqueue 时间过长,则意味着 CPU 资源紧张,无法及时处理所有请求。

另外可以切换到Kindling程序摄像头里这个耗时超200ms的复杂视图:

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_运维_06

继续滑动查看更多线程:

如何调控服务器CPU利用率的合理范围?10分钟快速掌握通用办法_java_07

可以看到有上百个线程在并发执行任务

(后经查代码确认这是某开发在应用里写的定时任务)

这就意味着CPU runqueue里有很多任务在排队,虽然这台机器的CPU利用率是在50%左右,看似不高,但并发线程越多,CPU调度起来越慢,所以有些请求如果被排在后面,执行就会较慢。

找到根因,调优办法很简单:

  • 增加CPU资源
  • 或者检查这些大量并发线程执行的任务是否能够优化,减少CPU的开销。
  • 或者调整进程的优先级,来控制CPU资源的分配

04 最后说点正经话

CPU利用率太低意味着CPU没有得到合理利用,资源浪费;过高又会对系统的性能造成影响。

大多数运维是根据经验去判断CPU的最高阀值,但是不同的业务情况,对CPU利用率的要求其实是不一样的。

大家都知道CPU打满到100%肯定会让应用崩溃,那80%对性能的影响又有多大?40%就靠谱了吗?

这个指标无法作为应用性能的衡量标准,究其根本,CPU runqueue的时间才是衡量关键。我们需要根据实际情况调优。

而Kindling程序摄像头是一个很好的工具,如上文所举的案例,我们能借助它“看到”不同CPU资源下,程序的实际执行情况,快速找到调优方向

05  附录 - Kindling程序摄像头技术介绍

Kindling程序摄像头精准还原程序执行现场的能力可以帮助我们:

  • 排障:分钟级内定位全资源种类故障根因
  • 调优:可视化展示资源配置对程序执行情况的影响

Kindling基于eBPF技术融合了Tracing,logging,metrics。

换句话说,它已经把该接口执行时刻的所有数据:

  • 网络、磁盘、内存等性能指标
  • mysql、redis等网络请求的连接信息和报文信息,
  • 日志,堆栈,锁信息以及文件IO信息
  • .......(欢迎来试用,发现Kindling更多能力)

都筛选捕捉出来,附着在对应的线程事件上,精准还原程序执行的现场。

07  附录 - 关于Kindling的更多资料

>> 如果想要了解它的实现原理,可以参考下文链接:

​eBPF程序摄像头——力争解决可观测性领域未来最有价值且最有挑战的难题​

>> 更多使用Kindling程序摄像头快速排障的生产环境案例,请查看:

​10分钟黄金期排障案例合集​

Kindling是个开源项目,开源之路道阻且长,希望大家可以给本文点个赞,一键三连,多多支持,感恩~

有任何问题可以添加小编WeChat:Xieyun-kindling

​Kindling官网​

​GitHub​



标签:10,Kindling,runqueue,调优,200ms,服务器,CPU,摄像头
From: https://blog.51cto.com/u_15454208/6045972

相关文章