CPU突然飙高,系统反应慢怎么排查,我来教教你

系统 其他OS
CPU 利用率过高的线程 ID 不断变化,说明线程创建过多,需要挑选几个线程 ID,通过 jstack 去线程 dump 日志中排查。最后有可能定位的结果是程序正常,只是在 CPU 飙高的那一刻,用户访问量较大,导致系统资源不够。

开发人员的基本能力。这不,有一位小伙伴去阿里面试,第一面就遇到了关于“CPU 飙高系统反应慢怎么排查”的问题?当时这位小伙伴不知从何下手。

今天,我给大家分享一下我的解决思路。

CPU 是整个电脑的核心计算资源,对于一个应用进程来说,CPU 的最小执行单元是线程。导致 CPU 飙高的原因有以下两个:

图片

1.CPU 上下文切换过多

对于 CPU 来说,同一时刻下每个 CPU 核心只能运行一个线程,如果有多个线程要执行,CPU 只能通过上下文切换的方式来执行不同的线程。上下文切换需要做两个事情

图片

保存运行线程的执行状态

让处于等待中的线程执行

这两个过程需要 CPU 执行内核相关指令实现状态保存,如果较多的上下文切换会占据大量CPU 资源,从而使得 CPU 无法去执行用户进程中的指令,导致响应速度下降。在 Java 中,文件 IO、网络 IO、锁等待、线程阻塞等操作都会造成线程阻塞从而触发上下文切换。

图片

2.CPU 资源过度消耗

图片

也就是在程序中创建了大量的线程,或者有线程一直占用CPU 资源无法被释放,比如死循环!CPU 利用率过高之后,导致应用中的线程无法获得 CPU 的调度,从而影响程序的执行效率!既然是这两个问题导致的 CPU 利用率较高,于是我们可以通过 top 命令,找到CPU 利用率较高的进程,在通过 Shift+H 找到进程中 CPU 消耗过高的线程,这里有两种情况。

CPU 利用率过高的线程一直是同一个,说明程序中存在线程长期占用 CPU 没有释放的情况,这种情况直接通过 jstack 获得线程的 Dump 日志,定位到线程日志后就可以找到问题的代码。

CPU 利用率过高的线程 ID 不断变化,说明线程创建过多,需要挑选几个线程 ID,通过 jstack 去线程 dump 日志中排查。最后有可能定位的结果是程序正常,只是在 CPU 飙高的那一刻,用户访问量较大,导致系统资源不够。

以上就是我对这个问题的理解!从这个问题来看,面试官主要考察实操能力,以及解决问题的思路。如果你没有实操过,但是你知道导致 CPU 飙高这个现象的原因,并说出你的解决思路,通过面试是没问题的。

责任编辑:武晓燕 来源: Tom弹架构
相关推荐

2023-12-26 11:39:50

CPU系统进程

2020-09-29 07:59:22

CPU系统性能

2023-10-26 09:00:58

Arthas工具CPU

2024-02-21 11:06:54

ArthasCPU工具

2021-03-31 13:45:59

CPU运维命令

2020-10-12 14:18:15

CPU技巧代码

2020-11-02 09:25:33

CPUJava线程

2022-08-26 01:46:33

注册中心NacosDNS

2021-02-26 13:35:46

JavaCPU内存

2024-03-06 11:14:13

ViteReact微前端

2015-09-06 09:26:46

解决办法开始菜单Windows 10

2023-10-20 13:30:36

代码接口

2022-07-26 08:14:16

注册中心ProviderConsumer

2019-01-23 10:11:43

Python爬虫IP

2020-05-29 16:57:27

磁盘阵列配置

2019-07-16 06:43:18

LinuxCPU占用率

2022-04-14 07:49:03

nmon监控Linux

2022-02-21 08:41:50

Redis

2020-03-23 10:06:05

工具代码开发

2023-02-10 21:18:10

IO测试磁盘
点赞
收藏

51CTO技术栈公众号