学习
实践
活动
工具
TVP
写文章

场景面试题CPU突然,系统反应慢怎么排查

这不,有一位小伙伴去阿里面试,第一面就遇到了关于“CPU系统反应慢怎么排查”的问题?当时这位小伙伴不知从何下手。 今天,我给大家分享一下我的解决思路。 CPU 是整个电脑的核心计算资源,对于一个应用进程来说,CPU 的最小执行单元是线程。导致 CPU的原因有以下两个: ENTER TITLE 1、CPU 上下文切换过多。 对于 CPU 来说,同一时刻下每个 CPU 核心只能运行一个线程,如果有多个线程要执行,CPU 只能通过上下文切换的方式来执行不同的线程。 最后有可能定位的结果是程序正常,只是在 CPU的那一刻,用户访问量较大,导致系统资源不够。 以上就是我对这个问题的理解!从这个问题来看,面试官主要考察实操能力,以及解决问题的思路。 如果你没有实操过,但是你知道导致 CPU这个现象的原因,并说出你的解决思路,通过面试是没问题的。 最后,我把之前分享的资料全部整理成了文字,希望能够以此来提高各位粉丝的通过率。

13920

CPU排查

SpringBoot应用 CPU排查 1. 准备 创建SpringBoot Web应用,访问/test/t1会死循环 访问/test/t2会死锁 2. 排查 3.1 排查CPU问题 此时使用top命令看一下进程 可以看到进程5510占用大量CPU。 此时看看进程5510里面是哪个线程导致这种结果 top -p 5510 -H 可以看到是线程5562和5563占用大量CPU,转化为16进制,方便带回查询堆栈定位。

9110
  • 广告
    关闭

    热门业务场景教学

    个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程,多款云服务器20元起。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    CPU负载CPU load average)场景1

    问题背景: 客户反馈机器使用非常卡顿,通过 top 命令可以看出,机器CPU负载(CPU load average)非常 CPU负载(CPU load average)趋于大于CPU核数时,说明服务器负载异常 CPU负载高一般原因为内存使用异常或磁盘性能异常导致 观察机器中top数据,发现内存使用率正常,但wa值很高,%wa指CPU等待磁盘写入完成的时间,怀疑磁盘性能负载过高导致 ? 通过 iotop 过滤到占用磁盘ID非常的线程 ID(TID),其实这里已经可以看到进程信息了,再通过 PS命令过滤线程ID确认业务进程,kill 进程后CPU负载降下来了 同时通过 iostat 可以看出磁盘读流量偏高 建议方案: 数据库等对磁盘性能要求的业务需选购性能更高的磁盘保证业务的高性能、可用性

    1.4K30

    【Linux】一招满你的cpu

    https://winaero.com/how-to-create-100-cpu-load-in-linux/ 一招cpu。 ? ?

    66020

    CPU问题排查

    文章目录 1、查询哪个进程占用CPU 2、进程哪个线程占用CPU 3、查询线程的堆栈信息 前言 CPU时,基本就是三板斧就可以找到具体占用CPU的线程信息,这样,你就看到CPU这么,是什么线程在捣乱了 1、查询哪个进程占用CPU 可以使用Top 或者top | grep 用户名 比如这里我们可以使用 top | grep deploy 查询当前用户deploy下面有哪些进程比较占用CPU,如下图,可以发现进程 28284比较占用CPU 2、进程哪个线程占用CPU 接着我们查看上述进程内是哪些线程在捣乱,使用命令top -H -p  PID 在这里我们使用top -H -p  28284,结果如下图,我们发现是有几个线程相对占用比较高 转换为16进制的数字:printf “%x\n” tid 2、 查询线程信息:jstack 28284 | grep 6ee5 -A 10 执行结果如下图,我们可以看到具体是我们的应用里的哪个线程占用CPU

    53200

    内存:你慢点行不行?CPU慢点你养我吗?内存:我不管!

    位于顶层的存储器速度最快,但是相对容量最小,成本非常。层级结构向下,其访问速度会变慢,但是容量会变大,相对造价也就越便宜。 如果该位是 1,则将在页表中查到的页框号复制到输出寄存器的 3 位中,再加上输入虚拟地址中的低 12 位偏移量。如此就构成了 15 位的物理地址。输出寄存器的内容随即被作为物理地址送到总线。 例如,对于 16 位地址和 4 KB 的页面大小, 4 位可以指定 16 个虚拟页面中的一页,而低 12 位接着确定了所选页面中的偏移量(0-4095)。 TLB 通常位于 CPUCPU 缓存之间,它与 CPU 缓存是不同的缓存级别。下面我们来看一下 TLB 是如何工作的。 然而,所有这些操作都必须通过少量指令完成,因为 TLB 丢失的发生率要比出错率很多。 ?

    38911

    Elasitcsearch CPU 使用率突然飙升,怎么办?

    这是系列文章的第二篇,主要探讨:Elasitcsearch CPU 使用率突然飙升,怎么办? 2、Elasticsearch CPU 使用率的内涵 线上环境 Elasticsearch CPU 使用率飙升常见问题如下: ——来自《死磕Elasticsearch 知识星球》 Elasticsearch 3、诊断 Elasticsearch CPU 使用率 3.1 核查 CPU 使用率 使用 cat nodes API 获取每个节点的当前 CPU 使用率。 GET _cat/nodes? 4、降低 CPU 使用率的实操方案 以下 Tips 概述了 CPU 使用率的最常见原因及其解决方案。 4.1 扩展集群 繁重的数据写入(indexing)和搜索负载会耗尽较小的线程池。 5、小结 建议提前做好集群监控和指标预警工作,“防范于未然”,结合节点的 CPU 核数最大化的提升线程池和队列的使用率。 你在实战环节有没有遇到 CPU 利用率问题?你是如何解决的呢?

    47640

    mysql的cpu定位

    导致数据库CPU很高的原因有很多种,一般和慢SQL也有关(因为每条SQL要么占CPU,要么占IO,大体是这样)。 (1)、如果服务器有多个mysql实例,需要通过top命令看看是哪个mysql实例导致的cpu(如果不是mysql导致的cpu,需要优化其他导致cpu的程序): ? (2)、定位到占用cpu的线程 通过top命令发现mysql占用CPU,再看mysql进程下有多少线程占用CPU:top -H -p [pid] ? (5)、如果有大量的慢sql,导致服务器cpu很高,mysql hang住,可以通过kill id(id在SHOW PROCESSLIST中显示 ),关掉疑似占CPU的线程,以确认是否能让CPU降下来 259200 #wait_timeout只作用于TCP/IP和Socket链接的线程,一般设置值和interactive_timeout一样 wait_timeout = 259200 ##新连接时候用到,在并发的系统里建议

    72120

    【实时性迷思】CPU究竟的有多快?

    【说在前面的话】 ---- 相对人的感官来说CPU的太快了——即便是人们常常用来描述时间短暂的“一眨眼功夫”对CPU来说也是及其“漫长”的好几百毫秒了——仔细想想有几个人能在一秒钟内连续眨十次眼睛呢? 那么CPU究竟的有多快呢?是很快、非常快还是快得不得了?如果我们继续站在人类的视角考虑这个问题,其抽象程度无异于思考“无穷大究竟是多大”。 让我们想象着周围的时间相对你突然都慢了下来,从微处理器的视角重新审视这个世界。 借助这个等效,我们就可以对CPU的处理能力建立更多量化的感官,比如1ms的时间内,CPU能做多少事情呢? 【结语】 ---- “1MHz就是1us”的等效为我们提供了一个基准,建立了关于“CPU多快”最直观的感受,同时也为评估代码尺寸、系统可靠性提供了有力的参考。

    35720

    CVM load average 问题(很有趣)

    问题场景:机器有些问题,业务访问正常,但cpu使用率这么低,负载这么,我的乖乖几个亿的负载,跑到银河系了 image.png 不懂就百度: load average 过高可能和睡眠进程有关系

    33230

    werfault进程使用CPU

    werfault进程是Windows vista 错误报告进程,是用来向微软反馈报告。是安全的正常进程。

    10560

    MySQL导致的CPU负载问题

    MySQL导致的CPU负载问题 今天下午发现了一个MySQL导致的向上服务器负载的问题,事情的背景如下: 在某个新服务器上,新建了一个MySQL的实例,该服务器上面只有MySQL这一个进程 0.0%st Cpu4 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us 只有一个核上面的负载是100%,其他的都是0%,而按照CPU使用率排序的结果也是mysqld的进程占用CPU比较多。 hi, 0.0%si, 0.0%st Cpu3 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 这里,我能想到的一个原因是5M的buffer pool太小了,会导致业务SQL在读取数据的时候和磁盘频繁的交互,而磁盘的速度比较慢,所以会提高IO负载,导致CPU的负载过高,至于为什么只有一个CPU的负载比较高

    99220

    CPU,频繁GC,怎么排查?

    处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题。当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警。 对于线上系统突然产生的运行缓慢问题,如果该问题导致线上系统不可用,那么首先需要做的就是,导出jstack和内存信息,然后重启系统,尽快保证系统的可用性。 CPU过高 在前面第一点中,我们讲到,CPU过高可能是系统频繁的进行Full GC,导致系统缓慢。而我们平常也肯能遇到比较耗时的计算,导致CPU过高的情况,此时查看方式其实与上面的非常类似。 对于不定时出现的接口耗时比较严重的问题,我们的定位思路基本如下:首先找到该接口,通过压测工具不断加大访问力度,如果说该接口中有某个位置是比较耗时的,由于我们的访问的频率非常,那么大多数的线程最终都将阻塞于该阻塞点 具体的可以根据具体情况分析: 如果是接口调用比较耗时,并且是不定时出现,则可以通过压测的方式加大阻塞点出现的频率,从而通过 jstack查看堆栈信息,找到阻塞点; 如果是某个功能突然出现停滞的状况,这种情况也无法复现

    2.5K30

    面试杂谈 - CPU占用如何排查

    程序里少不了运算,如果不是环境太恶劣,CPU基本是能支撑应用运行的。但如果发现CPU居高不下,就需要思考是否程序有问题。 当服务器CPU居高不下,可以从下面几个方面入手定位问题。 00:05:11 java -jar acupjava-1.0-SNAPSHOT.jar 找到进程中CPU的线程 tid 打印出线程线程基本信息,找到cpu百分比高的一个或几个线程,记住它们的tid。 PS:栗子质量不好,全是0.0%,不要在意~ [root@iZba13i1mo82ot7a3lhq5oZ ~]# ps -mp 26016 -o THREAD,tid,time USER %CPU 的线程 打开文件,搜索tid所在位置,可以看到线程栈,由此分析定位可能有问题的代码。 的问题基本就能定位出来了。

    66031

    linux负载cpu使用率低_cpu工作负载

    推广开来,n 个 CPU 的计算机,可接受的系统负载最大为n.0。 芯片厂商往往在一个 CPU 内部,包含多个CPU核心,这被称为多核CPU。 在系统负载方面,多核 CPU 与多 CPU 效果类似,所以考虑系统负载的时候,必须考虑这台计算机有几个 CPU、每个 CPU 有几个核心。 延伸阅读: 性能基础之CPU、物理核、逻辑核概念与关系 CPU使用率 如果我们观察在给定时间间隔内通过CPU的不同进程,则利用率百分比将表示相对于CPU执行与每个进程相对应的指令的那个时间间隔的时间部分 注意输入/输出(I/O)操作 在本文反复强调了不间断休眠状态非常重要 (第一张图中的D),因为有时你可以在计算机中找到非常的负载值,然而不同的运行过程使用率相对较低。 高于1的值,尤其是最后5分钟和15分钟的负载平均值是一个明显的症状,要么我们需要改进计算机的硬件,通过限制用户可以对系统的使用来节省更少的资源,或者除以多个相似节点之间的负载。

    16440

    CPU负载的排查办法

    今天线上一个tomcat进程cpu负载100%。按以下步骤查出原因。 1.执行top -c命令,找到cpu最高的进程的id 2.执行top -H -p pid,这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。 找到CPU负载的线程tid 8627, 把这个数字转换成16进制,21B3。 3.执行jstack -l pid,拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。 那只能说明是jvm在耗cpu。很容易想到是疯狂的GC,按关键字 “overhead” 搜一下系统日志, 发现 “GC Overhead”日志。问题明了了。

    13210

    谈谈Tomcat占用cpu的问题

    持续负载,实际上当线程进入死锁之后是等待获取对象所被执行,此时CPU是空闲的。 导致CPU负载持续的原因是线程进入了死循环,导致CPU持续在工作,此时线程的状态应该是Runnable,而不是Blocked。 排查Java进程导致CPU持续的方法 在Linux环境下,通过如下步骤可以实现对Java进程CPU持续负载的问题排查: 通过jps命令找到Java进程ID,并使用top命令确定CPU占用的进程是否为 Tomcat的CPU占用的原因总结 线程死锁和线程死循环不是一个概念,千万不要弄错。 由于应用程序出现堆内存空间不够用导致频繁GC,也会导致CPU使用率。 如果应用日志输出非常频繁,也会导致CPU使用率持续

    1.4K20

    CPU深度学习模型,FPS也可以达100帧

    这里需要注意的是CPU需要扩展支持,添加扩展支持的代码如下: ie.add_extension(cpu_extension, "CPU") 创建可执行的网络的代码如下: # CPU 执行 exec_net = ie.load_network(network=net, device_name="CPU", num_requests=2) # 计算棒执行 lm_exec_net = ie.load_network (network=landmark_net, device_name="MYRIAD") 这里我们创建了两个可执行网络,两个深度学习模型分别在CPU与计算棒上执行推理,其中第一个可执行网络的推理请求数目是 人脸检测演示 03 基于OpenVINO的人脸检测模型与landmark检测模型,实现了一个CPU级别实时人脸检测与landmark提取的程序,完整的代码实现如下: def face_landmark_demo , "CPU") # LUT lut = [] lut.append((0, 0, 255)) lut.append((255, 0, 0)) lut.append

    1.3K20

    业界 | 英特尔的CPU,现在被禁止分了

    这一次,英特尔的 CPU 微码许可协议中包含了「禁止用户分」条款。这意味着人们使用任何 Benchmark 软件对自己的 CPU 进行评测,并将分数和对比结果公布成为了「非法」动作。 ? 近日,英特尔正在更新旗下 CPU 的可加载微码,来应对多种侧通道和 timing 攻击。 很多人认为这就是英特尔针对安装补丁之后 CPU 性能下降的「补救方法」。 而另一些网友则对英特尔的行动表示了嫌恶,johnklos 就问道: 我真的很好奇,英特尔是如何想像分也是能被强行禁止的。 看来,在 CPU 漏洞危机过后,英特尔还有很多事情要做。 ?

    48020

    systemd --user进程CPU占用问题分析

    2.4.systemd进程吃CPU的原因 关于进程跟踪我们很容易想到strace命令。 我们对2.1章节中创建的test3的systemd进程进行跟踪。 使用率太高是因为mount挂载点太多,mount有更新后,通过dbus通知到systemd重新遍历所有mount, 遍历操作比较耗cpu。 对于什么情况下出现systemd占用,我们得出如下结论: systemd版本大于226(ubuntu1604为229)+docker版本为19.03.14,无论runc做了什么操作,dbus会通知systemd 重新遍历 mount,遍历mout过多(cat /proc/mounts |wc命令查看)会导致systemd进程吃CPU。 ,如果遍历mount过多(cat /proc/mounts |wc命令查看,700个会吃30%CPU,1000个会吃50%左右CPU)就会导致systemd进程吃CPU

    45840

    扫码关注腾讯云开发者

    领取腾讯云代金券