写点什么

我的快速调优线上服务器 CPU 利用率通用办法,震惊面试官

作者:KINDLING
  • 2023-02-09
    浙江
  • 本文字数:1829 字

    阅读完需:约 6 分钟

我的快速调优线上服务器CPU利用率通用办法,震惊面试官

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

绝大部分开发在面试时都会被面试官问到一个问题:

“请举一个在以前工作过程中你觉得自己做的非常不错的事例”

换言之:“请吹一个牛”

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

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

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

02 同学,请你展开说说

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

  • 查个商品,页面转啊转......

  • 下个单,页面转啊转......

  • 看个买家秀,页面转啊转......

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


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

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

  • 我们负责的应用有个接口,逻辑很简单,主要是数据计算

  • 正常耗时一般都在 130ms 左右

  • 但它总时不时的飚到 200ms 以上

  • 应用所在机器的内存、网络、磁盘等资源都正常,CPU 在 50%左右

  • 并发量不高

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


03 这一波操作,秀!

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

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


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

1. 正常-200ms 以下:


2. 异常-200ms 以上:


可以清楚的看到,耗时 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 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 是个开源项目,开源之路道阻且长,希望大家可以给本文点个赞,一键三连,多多支持,感恩~

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

Kindling官网

GitHub


发布于: 刚刚阅读数: 3
用户头像

KINDLING

关注

还未添加个人签名 2022-11-10 加入

还未添加个人简介

评论

发布
暂无评论
我的快速调优线上服务器CPU利用率通用办法,震惊面试官_Java_KINDLING_InfoQ写作社区