CPU飙升的问题
本文转载自CPU飙升的问题
问题发现
事情是这样的,最近小码仔负责的项目预定今天凌晨2点上进行版本更新。前几天测试小姐姐对网站进行压力测试,观察服务的CPU、内存、load、RT、QPS等各种指标。
在压测的过程中,测试小姐姐发现我们其中一个接口,在QPS上升到400以后,CPU利用率急剧升高。
在这里我不再对CPU
、内存
、load
、RT
、QPS
等做过多赘述,毕竟这几个点中的任何一个拿出来探讨,一篇文章都不一定写的完。有兴趣深究的小可爱就自己动手查一下吧。
这里我仅对QPS
及CPU利用率
做简单的概述。
QPS每秒查询率,QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。QPS越高说明,在特定时间内服务器所处理的流量越大。
CPU利用率是来描述CPU的使用情况,它表明了一段时间内CPU被占用的情况。使用率越高,说明机器在这个时间上运行了很多程序,反之较少。
了解了这两个基本的点,接下来就来一起看看我具体是怎么定位的吧。
问题定位
测试小姐姐反馈这个问题后,我登录到服务器,做了以下操作:
定位进程
登录服务器,执行top命令,查看CPU占用情况:
$top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
44529 root 20 0 4289m 874m 13312 S 123.0 10.9 10:39.73 java
top
命令查看所有进程占系统CPU的排序,它是Linux下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况,类似于Windows的任务管理器。
我们来看一下这些指示符代表什么:
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级,正值表示低优先级
VIRT — 进程使用的虚拟内存总量,单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小,单位kb。RES=CODE+DATA
SHR — 共享内存大小,单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计,单位1/100秒
COMMAND — 进程名称(命令名/命令行)
通过执行top
命令,我看到,进程ID为44529的Java进程的CPU占用率达到了123%,基本可以定位到是我们的Java应用导致整个服务器的CPU占用率飙升。
定位线程
当然,Java是单进程多线程的,那么,接下来我就看了这个PID=44529的这个Java进程中的各个线程的CPU使用情况,同样是用top命令:
$top -Hp 44529
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
44580 root 20 0 4289m 874m 13312 S 16.2 10.9 3:02.96 java
通过执行top -Hp 44529
命令,我发现,在44529这个进程中,ID为44580的线程占用CPU最高。
定位代码
通过top命令,我定位到了导致CPU使用率较高的具体线程, 接下来就要看一下具体是哪一行代码存在问题。
首先,我把44580这个线程转成16进制:
$printf %x 44580
ae24
接下来,根据该16进制值去打印的堆栈日志内查询,查看该线程所驻留的方法位置。并通过jstack
命令,查看栈信息:
$jstack 44529 |grep -A 200 ae24
"System Clock" #28 daemon prio=5 os_prio=0 tid=0x00007efc19e8e800 nid=0xae24 waiting on condition [0x00007efbe0d91000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386)
at com.*.order.Controller.OrderController.detail(OrderController.java:37) //业务代码阻塞点
通过以上代码,我们可以清楚的看到,OrderController.java的第37行是有可能存在问题的。
然后我找到项目中OrderController.java的第37行,仔细分析发现由于自己的粗心,代码存在逻辑上的漏洞。修改重构之后,问题解决。
总结
以上就是本次问题排查的整个过程。主要用到的有:top
,printf
,jstack
等指令。
- 使用
top
指令查看当前占用CPU较高的进程PID; - 查看当前进程消耗资源的线程PID:
top -Hp PID
- 将线程PID转为16进制,根据该16进制值去打印的堆栈日志内查询,查看该线程所驻留的方法位置。
- 通过
jstack
命令,查看栈信息,这步基本上已经能够定位大多数问题了。
CPU飙升的问题的更多相关文章
- 记一次CPU飙升BUG
图文地址:https://mp.weixin.qq.com/s?__biz=Mzg3NjEzODQ4NQ==&mid=2247483690&idx=1&sn=7c926f400 ...
- 【原创】记一次MySQL大表高并发写入引发CPU飙升的排障过程
目录 一.故障现象... 1 二.初步分析... 2 三.排障过程... 2 1.排查是否QPS或insert并发请求上升导致问题发生... 2 2.排查是否锁资源等待或block导致了insert变 ...
- .dhpcd导致cpu飙升问题
因公司有业务服务器在阿里云上面,阿里云后台报警说,“有恶意程序在挖矿”,引起了高度重视,于是我登陆服务器进行排查. 登陆云服务器:系统centos7.5 第一步使用top查看资源情况. top 可以清 ...
- pt-kill--- MySQL数据库CPU飙升紧急处理方法
MySQL数据库CPU飙升紧急处理方法 [日期:2014-01-22] 来源:Linux社区 作者:hcymysql [字体:大 中 小] 运行平稳的数据库,如果遇到CPU狂飙,到80% ...
- 线上CPU飙升100%问题排查,一篇足矣
一.引子 对于互联网公司,线上CPU飙升的问题很常见(例如某个活动开始,流量突然飙升时),按照本文的步骤排查,基本1分钟即可搞定!特此整理排查方法一篇,供大家参考讨论提高. 二.问题复现 线上系统突然 ...
- 面试连环炮系列(八):服务器CPU飙升100%怎么排查
服务器CPU飙升100%怎么排查 执行"top"命令,查看当前进程CPU占用的实时情况,PID列是进程号,确定是哪个应用程序的问题. 如果是Java应用导致的,怎么定位故障原因 执 ...
- MySQL数据库CPU飙升紧急处理方法
MySQL数据库CPU飙升紧急处理方法 运行平稳的数据库,如果遇到CPU狂飙,到80%左右,那一定是开发写的烂SQL导致的,DBA首先要保证的是,数据库别跑挂了,所以我们要把那些运行慢的SQL杀死并记 ...
- 【转】Java程序CPU飙升问题排查方法
windows环境下cpu飙升问题 线上某台runtime机器(windows Server)cpu报警,这种情况初步就是代码里面死循环了,先把机器下线了保证不再有新的任务分配进来,然而cpu使用依然 ...
- 线上CPU飙升100%问题排查
本文转载自线上CPU飙升100%问题排查 引子 对于互联网公司,线上CPU飙升的问题很常见(例如某个活动开始,流量突然飙升时),按照本文的步骤排查,基本1分钟即可搞定!特此整理排查方法一篇,供大家参考 ...
随机推荐
- Jumpserver-堡垒机
Jumpserver-堡垒机 1.基于Docker搭建Jumpserver堡垒机 1.1 下载镜像 1.2 运行镜像 1.2.1 官网步骤-Docker快速启动 1.3 浏览器访问 2.Jumpser ...
- GeoMesa Java API-写入与查询数据
GeoMesa Java API-写入与查询数据 写入数据 DataStore SimpleFeatureType SimpleFeature 写入 查询数据 几个常用查询条件 设置最大返回条目: 设 ...
- java使用Test测试接口类
package com.jy.demo.web; import java.util.Map; import org.junit.BeforeClass; import org.junit.Test; ...
- Go语言学习-import
import我们在写Go代码的时候经常用到import这个命令用来导入包文件,而我们经常看到的方式参考如下:import("fmt")然后我们代码里面可以通过如下的方式调用fmt. ...
- nginx教程<二>(高可用)
1.nginx集群 对于访问量较大的网站来说,随着流量的增加单台服务器已经无法处理所有的请求,这时候需要多台服务器对大量的请求进行分流处理,即负载均衡. 而如果实现负载均衡,必须在网站的入口部署服务器 ...
- Pytest(10)assert断言
前言 断言是写自动化测试基本最重要的一步,一个用例没有断言,就失去了自动化测试的意义了.什么是断言呢? 简单来讲就是实际结果和期望结果去对比,符合预期那就测试pass,不符合预期那就测试 failed ...
- HDU6430 Problem E. TeaTree【dsu on tree】
Problem E. TeaTree Problem Description Recently, TeaTree acquire new knoledge gcd (Greatest Common D ...
- ACM#学习心得0
加入实验室也有些日子了,这是第一个近来的小小学习心得 1.在之前的训练题和考核题以及平时刷过的题中,我发现自己对字符串这一块的基础知识掌握还是比较差的,总是不能正确的接收的字符或字符串. 这两个星期, ...
- HOJ1867 经理的烦恼
My Tags (Edit) Source : HCPC 2005 Spring Time limit : 2 sec Memory limit : 32 M Submitted : ...
- 2019 ICPC Asia Taipei-Hsinchu Regional Problem K Length of Bundle Rope (贪心,优先队列)
题意:有\(n\)堆物品,每次可以将两堆捆成一堆,新堆长度等于两个之和,每次消耗两个堆长度之和的长度,求最小消耗使所有物品捆成一堆. 题解:贪心的话,每次选两个长度最小的来捆,这样的消耗一定是最小的, ...