性能文章>CPU 优化高级篇:Linux系统中CPU占用率较高问题排查思路与解决方法>

CPU 优化高级篇:Linux系统中CPU占用率较高问题排查思路与解决方法转载

1月前
248300

目录

第一篇:CPU性能优化基础篇:一定要了解Linux CPU哪些基本概念 
第二篇:CPU 优化高级篇:Linux系统中CPU占用率较高问题排查思路与解决方法
第三篇:CPU 优化高级篇:Java  CPU 高的原因和排查方法  :如何定位Java  消耗CPU最多的线程
第四篇:CPU 优化高级篇:Java  CPU 高的原因和排查方法  :学会Java死锁和CPU 100% 问题的排查技巧
第五篇:CPU 优化线上实战篇:Java 生产环境 CPU 跑满 & 大量长耗时的问题排查 & 解决
第六篇:CPU 优化线上实战篇:Java   JVM  频繁 GC的原因和排查方法

 

导语

作为 Linux 运维工程师,在日常工作中我们会遇到 Linux服务器上出现CPU负载达到100%居高不下的情况,如果CPU 持续跑高,则会影响业务系统的正常运行,带来企业损失。

正文:

面对 Linux服务器上出现CPU负载很多运维的同学往往会不知所措,对于CPU过载问题通常使用以下两种方式即可快速定位:

 

方法一

第一步:使用

top命令,然后按shift+p按照CPU排序

找到占用CPU过高的进程的pid

第二步:使用

top -H -p [进程id]

找到进程中消耗资源最高的线程的id

第三步:使用

echo 'obase=16;[线程id]' | bc或者printf "%x\n" [线程id] 

将线程id转换为16进制(字母要小写)

bc是linux的计算器命令

第四步:执行

jstack [进程id] |grep -A 10 [线程id的16进制]”

查看线程状态信息

 

方法二

第一步:使用

top命令,然后按shift+p按照CPU排序

找到占用CPU过高的进程

第二步:使用

ps -mp pid -o THREAD,tid,time | sort -rn

获取线程信息,并找到占用CPU高的线程

第三步:使用

echo 'obase=16;[线程id]' | bc或者printf "%x\n" [线程id]

将需要的线程ID转换为16进制格式

第四步:使用

jstack pid |grep tid -A 30 [线程id的16进制]

打印线程的堆栈信息

 

案例分析

场景描述

生产环境下JAVA进程高CPU占用故障排查

解决过程

1、根据top命令,发现PID为2633的Java进程占用CPU高达300%,出现故障。

2、找到该进程后,如何定位具体线程或代码呢,首先显示线程列表,并按照CPU占用高的线程排序:

[root@localhost ~]# ps -mp 2633 -o THREAD,tid,time | sort -rn

显示结果如下:

找到了耗时最高的线程(TID)3626,占用CPU时间有12分钟了!

3、将需要的线程TID转换为16进制格式

[root@localhost ~]# printf "%x\n" 3626
e18


4、最后使用jstack命令打印出该进程下面的此线程的堆栈信息:

[root@localhost ~]# jstack 2633 |grep "e18" -A 30

相比故障的解决而言,发现故障也同等的重要!市场上的大多数监控软件都能实现服务器负载的实时观测,比如:Zabbix、Nagios、阿里云监控(针对云服务器)等。但是当中大部分的软件都需要运维同学主动去设置规则或者检测才能发现问题,如何被动的也能收到告警呢?

推荐大家一个实用的运维软件——王教授,对于业务部署在阿里云上的用户,只需绑定需要监控的只读AcessKey,即可将云上资源的告警信息及时通知给对应的团队成员。


化主动为被动的方式,一方面减轻了运维工程师的工作,另一方面也减小了运维漏看或者忽略告警的情况发生。

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

记一次由 MQ SDK 太简陋引发的生产事故
本文正在参加「Java应用线上问题排查经验/工具分享」活动 背景由于公司所有系统都在云上,所以服务器/数据库/中间件啥的用的都是某云服务商的产品,包括 MQ/Redis 等。​某周边小系统在流程改造过
一次 RocketMQ 顺序消费延迟的问题定位
问题背景与现象昨晚收到了应用报警,发现线上某个业务消费消息延迟了 54s 多(从消息发送到MQ 到被消费的间隔):```2021-06-30T23:12:46.756 message processi
HeapDump性能社区Full GC异常问题排查实战案例精选合集
处理过线上问题的同学基本都遇到过系统突然运行缓慢,CPU 100%,以及 Full GC 次数过多的问题。这些问题最终导致的直观现象就是系统运行缓慢,并且有大量的报警。本期小编集合了HeapDump性
记一次异步日志设置不合理导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。其中有一次,碰到了一个异步日志设置不合理导致线程阻塞的情况。用文字记
Dubbo No provider问题排查思路
使用过Dubbo的朋友很多都碰到过如下报错: No provider available for the service org.newboo.basic.api.MyDemoService from registry 127.0.0.1:2181 on the consumer 127.0.0.
Java 问题排查技术分享
最近翻看以前写的 PPT, 发现了在2019年做的一次技术分享,关于 Java 问题排查,由于没什么公司机密可言,整理下分享给大家~线上问题处理流程直接放PPT截图吧,现在看来依然不过时问题排查可从三个方面入手知识:有些问题,思考一下就有答案,就像传说中多隆那样,回忆下就知
我好像发现了一个Go的Bug?
从一次重构说起这事儿还得从一次重构优化说起。最近在重构一个路由功能,由于路由比较复杂,需求变化也多,于是想通过责任链模式来重构,刚好这段时间也在 Sentinel-Go 中看到相关源码。用责任链模式,最大的好处是可以针对每次请求灵活地插拔路由能力,如:这样实现会在每次请求到来时去new
Netty堆外内存泄漏排查盛宴
最近在做一个基于 Websocket 的长连中间件,服务端使用实现了 Socket.IO 协议(基于WebSocket协议,提供长轮询降级能力) 的 netty-socketio 框架,该框架为 Netty 实现,鉴于本人对 Netty 比较熟,并且对比同样实现了 Socket.IO 协议的其他框架