CPU飚高或内存溢出该怎么办?

通过top命令检查CPU和内存占用,关注慢SQL导致的性能问题,查找死锁迹象,以及分析线程状态判断是否由频繁上下文切换或资源不足引起的问题。使用jstack分析线程堆栈,转换十六进制线程ID,定位问题源。若线程数过多未及时销毁可能导致内存溢出,需优化线程管理和资源回收。
摘要由CSDN通过智能技术生成

一.整体思路和结论

1.1.思路

  1. 用top命令查看哪个进程占用的cpu比较高(或者内存飚高)。
  2. 用top -Hp pid查看具体的哪个线程导致的,这里面又分两种情况。
  3. 一般情况下,内存飚高会影响CPU。反之cpu飚高,内存有可能不会很高。
  4. cpu小于百分之80是合理的。

1.2.结论

  1. top命令查看是cpu飚高还是内存飚高,还是两者都飚高。
  2. 引起的原因
  1. 有慢sql,引起cpu飚高(内存可能飚高)。
    出现CPU飚高或者内存飚高的情况,先查慢sql,是否有全表扫描,或者全局模糊查询的情况。
SELECT * FROM information_schema.processlist WHERE info IS NOT NULL ORDER BY TIME DESC;
select * from information_schema.processlist t where t.COMMAND='Query';
  1. 有死锁,在jstack文件的最下方找。
  2. 线程数多(没有及时销毁)。
  3. 频繁切换上下文(其实和3是一样的,导致线程数较多)。
  4. 资源不够用,申请扩容。

二.每个线程都不是很高,但是线程数较多,cpu飚高

2.1.资源不够,CPU飚高

2.1.1.创建show1.txt文件(root)

vim /usr/show1.txt 

2.1.2.赋权(root)

chmod a+w /usr/show1.txt

为什么我们要给所有的用户赋权呢?

因为我们的java进程是运行在admin用户下面的,所以要通过root给admin赋权

2.1.3.top命令查看当前进cpu高的进程(root)

top

在这里插入图片描述

2.1.4.打印日志到show1.txt文件中(admin)

jstack 6140 > /usr/show1.txt

注意这里6140是进程

2.1.5.查看当前进程中哪个线程利用cup比较高

top -p 6140 -H

2.1.6.因为jstack的命令是用十六进制表示的,所以我们现在把十六进制转成十进制

在这里插入图片描述

printf  "%x"  26719

对应的就是 685f

注意这里 26719是6140进程下面的线程

2.1.7.到show1.txt中查看

less /usr/show1.txt

在这里插入图片描述
这个时候就要考虑资源是否够用的情况了。

2.1.18.如何判断cpu是否够用

在这里插入图片描述

2.2.频繁切换上下文把cpu飚高

2.2.1.先top

在这里插入图片描述

2.2.2.top -Hp pid

在这里插入图片描述

2.2.3.原因分析

在这里插入图片描述

2.2.4.vmstat 2(两秒刷新一次,用vmstat命令)

在这里插入图片描述

top -Hp pid

在这里插入图片描述

2.2.5.printf “%x\n” pid

在这里插入图片描述

2.2.6.jstack

jstack pid(进程id) | grep 线程id(十六进制的,printf “%x\n” pid的结果)-A 30

jstack 23745  |  grep  5cff  -A  30

在这里插入图片描述

2.2.7.原因分析

在这里插入图片描述
在这里插入图片描述

三.每个线程都不是很高,但是线程数较多(没有及时销毁),把内存飚高

3.1.由于多线程没有及时回收,导致内存溢出,有可能CPU也会飚高

3.1.1.问题:应用总是爆内存

在这里插入图片描述
问题排查:猜测是因线程太多导致的

ps -ef |grep java

查到PID为12179后,执行top -Hp //查看线程
所以这里执行top -Hp 12179,查到该线程的用户为admin
切换用户至admin,使用su username命令,所以这里执行
su admin
执行jstack
在这里插入图片描述

名称前缀为****-pool 的线程数量高达1.8个w
然后看代码排查问题
在这里插入图片描述
主要是这里开启了多线程。
本地分析
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
解决方法
在这里插入图片描述
退出出最后关闭线程池。
使用完线程池一定记得回收,否则跑着跑着就内存爆炸崩溃。

3.1.2.cup飚高,有台机器不定时的会挂

现象描述,生产应用总共4个pod节点,不定时的有台机器就会挂掉,其它中心调用自己部门的接口会超时,情况定位。
数据库右模糊匹配,搜出来的数据量大,超时,导致CPU飚高。

3.1.3.cup飚高,有台机器不定时的会挂

有个查询语句没有加查询条件,导致全表扫描,由于tomcat在一直等数据库的返回,导致应用CPU飚高。

四.有一个或者几个线程cpu特别高,其它线程正常,把cpu飚上去

4.1.死锁导致CPU飚高(有可能内存也会飚高)

4.1.1.模拟写了一个死锁

在这里插入图片描述

4.1.2.用top查看进程的状态

top命令
在这里插入图片描述

4.1.3.用jstack命令先创建一个文件

在这里插入图片描述

top -p 23234 -H

在这里插入图片描述

4.1.5.把线程id转成16进制

在这里插入图片描述

4.1.6.less show.txt文件

这个时候来查看show的文件 通过上图中的十六进制5ae1的线程ID

在这里插入图片描述
这个时候就可以具体的看到哪行代码的问题了。

4.1.7.补充,查看有没有死锁

在show.txt中,拉到文档最下面,就可以看到下面死锁的情况了
在这里插入图片描述

  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值