关于java:CPU利用率在什么范围会对系统性能产生影响如何做性能调优

33次阅读

共计 2042 个字符,预计需要花费 6 分钟才能阅读完成。

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

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

“请举一个在以前工作过程中你感觉本人做的十分不错的事例”

换言之:“请吹一个牛”

个别人呢,这个牛他会悠着点吹,大多数合乎“28 定律”,8 分瞎话 2 分润色

然而有一位不愿走漏姓名的高级开发同学曾大言不惭的说:

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

02 同学,请你开展说说

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

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

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

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

哦哦哦,我须要先把这个问题背景交代分明:

  1. 咱们负责的利用有个接口,逻辑很简略,次要是数据计算
  2. 失常耗时个别都在 130ms 左右
  3. 但它总时不时的飚到 200ms 以上
  4. 利用所在机器的内存、网络、磁盘等资源都失常,CPU 在 50% 左右
  5. 并发量不高

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

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

正文完
 0