CPU监控_安卓cpu实时监控

CPU监控_安卓cpu实时监控一,关键概念1,ContextSwitches(上下文切换)2,TherunQueue(运行队列)3,CPU的使用率二,CPU监控2.1,健康状态下CPU基准线2.2,vmstat使用2.2.1

大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

 

服务器内核有个调度器,其负责调度两种资源(线程,中断)。调度器针对不同的资源有不同的优先级,下面三个优先级从高到低依次如下:

  1. 中断:设备完成操作后通知内核,例如硬件设备受到一个IO请求
  2. 系统进程:所有内核操作都在这个级别
  3. 用户进程:这些进程一般都运行在用户空间中,其在调度器中优先级比较低

下面分别详细介绍一些关键概念

一,关键概念

1,Context Switches(上下文切换)

现在的CPU大部分在同一颗核上同时只能跑一个线程,就算超线程处理器,微观上看同一时刻也只是跑一个线程。Linux内核看每颗CPU处理器都是独立处理器。一个Linux内核同时可以调度50-50000个线程。在每颗处理器中调度器都需要调度线程合理的使用CPU。每个线程分配了一个时间片的时间使用CPU,一旦时间片用完了或者高优先级资源(例如中断)需要占用CPU,该线程就会放回到调度队列中让高优先级资源使用CPU。这样的线程切换就是所谓的Context Switch(上下文切换)。每发生一次上下文切换资源就会从CPU的使用中挪到调度队列中。一个系统单位之间内上下文切换的次数越多,表明内核进行的工作越繁忙。

2,The run Queue(运行队列)

每个CPU都维护了一个运行队列,理想来讲调度器会一直处于运行和执行线程,这些线程不是处于运行状态就是休眠状态(等待IO或者阻塞)。如果CPU子系统的使用率非常高的情况下,内核调度程序可能跟不上系统的需要。会导致运行队列越来越大,同时一些可运行的线程一直得不到调度。

下面说明下load的概念:

load经常用来描述运行队列的状况。其含义是正在执行的线程个数与运行队列中线程个数的和。例如一个双核系统,现在有两个线程在执行,有4个线程在运行队列。

所以此时load为6。Linux提供了最近1min,5min,15min的统计。

3,CPU的使用率

CPU的使用率是指CPU使用百分比,该指标是系统CPU使用情况重要指标。大部分监控工具提供了如下四个维度的监控

  1. User Time(用户时间):用户空间中的用户态线程使用CPU耗时占整个时间段比例
  2. System Time(系统时间):系统线程(or 进程)使用CPU耗时占整个时间段比例
  3. Wait IO:因为等待IO请求空闲时间占整个时间段比例
  4. Idle:完全空闲时间占比

二,CPU监控

2.1,健康状态下CPU基准线

  1. 单核CPU,load不超过3个task。一般线上机器单核load超过1.5就该引起注意了。
  2. User Time不超过65%-70%
  3. System Time不超过30%
  4. 一般线上情况CPU使用率到80%,就应该加机器,或者想办法优化了。
  5. 上线文切换直接相关CPU的使用程度

2.2,vmstat使用

2.2.1 使用办法

vmstat {采样时间间隔,单位为秒}

vmstat 
1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 
2  
0 
181124 
150552   
7404 
606060    
0    
0   
380   
185    
0    
0 
47  
1 
50  
1
 
1  
0 
181124 
149496   
7412 
606736    
0    
0   
229    
17 
1245 
1757 
25  
1 
73  
0
 
1  
0 
181124 
148552   
7420 
607564    
0    
0   
280    
39 
1331 
1858 
26  
1 
72  
1
 
1  
0 
181124 
145484   
7428 
610820    
0    
0  
1053    
23 
1161 
1728 
24  
1 
73  
1

下面只解释CPU相关的列

各列名称
含义
备注
r 运行队列中任务数(线程数)  
b 被阻塞或者等待IO请求的线程数  
in
interrupte:处理的中断数  
cs context switches:上下文切换数  
us user time:用户进程消耗时间比  
sy system time:系统进程消耗时间比  
id idle:空间时间比  

2.2.2 Case分析

case1:

# vmstat 
1
procs memory swap io system cpu
r b swpd   free  buff  cache  si    so bi bo    in cs us sy         wa id
3 
0 
206564 
15092 
80336 
176080 
0     
0   
0 
0     
718 
26 
81 
19        
0 
0
2 
0 
206564 
14772 
80336 
176120 
0     
0   
0 
0     
758 
23 
96 
4         
0 
0
1 
0 
206564 
14208 
80336 
176136 
0     
0   
0 
0     
820 
20 
96 
4         
0 
0
1 
0 
206956 
13884 
79180 
175964 
0     
412 
0 
2680  
1008 
80 
93 
7        
0 
0
2 
0 
207348 
14448 
78800 
175576 
0     
412 
0 
412   
763 
70 
84 
16        
0 
0
2 
0 
207348 
15756 
78800 
175424 
0     
0   
0 
0     
874 
25 
89 
11        
0 
0
1 
0 
207348 
16368 
78800 
175596 
0     
0   
0 
0     
940 
24 
86 
14        
0 
0
1 
0 
207348 
16600 
78800 
175604 
0     
0   
0 
0     
929 
27 
95 
3         
0 
2
3 
0 
207348 
16976 
78548 
175876 
0     
0   
0 
2508  
969 
35 
93 
7         
0 
0
4 
0 
207348 
16216 
78548 
175704 
0     
0   
0 
0     
874 
36 
93 
6         
0 
1
4 
0 
207348 
16424 
78548 
175776 
0     
0   
0 
0     
850 
26 
77 
23        
0 
0
2 
0 
207348 
17496 
78556 
175840 
0     
0   
0 
0     
736 
23 
83 
17        
0 
0
0 
0 
207348 
17680 
78556 
175868 
0     
0   
0 
0     
861 
21 
91 
8         
0 
1

从这个case可以看出:

  1. 当前CPU几乎都完全吃满,同时可运行队列中任务有堆积
  2. 系统有在使用swap,情况非常糟糕
  3. 内存也非常紧张,可用内存很少
  4. 线程上下文切换比中断少很多。猜测是个单线程在工作的样子(需要业务知识验证),如果不是从业务知识下判断
  5. 线上服务一般不允许出现这么糟糕的情况

case 2:

# vmstat 
1
procs memory swap io system cpu
r b swpd    free    buff    cache   si so   bi  bo      in  cs      us sy   wa id
2 
1 
207740  
98476   
81344 
180972    
0 
0     
2496 
0      
900 
2883    
4 
12    
57 
27
0 
1 
207740  
96448   
83304 
180984    
0 
0     
1968 
328    
810 
2559    
8 
9     
83 
0
0 
1 
207740  
94404   
85348 
180984    
0 
0     
2044 
0      
829 
2879    
9 
6     
78 
7
0 
1 
207740  
92576   
87176 
180984    
0 
0     
1828 
0      
689 
2088    
3 
9     
78 
10
2 
0 
207740  
91300   
88452 
180984    
0 
0     
1276 
0      
565 
2182    
7 
6     
83 
4
3 
1 
207740  
90124   
89628 
180984    
0 
0     
1176 
0      
551 
2219    
2 
7     
91 
0
4 
2 
207740  
89240   
90512 
180984    
0 
0     
880 
520     
443 
907     
22 
10   
67 
0
5 
3 
207740  
88056   
91680 
180984    
0 
0     
1168 
0      
628 
1248    
12 
11   
77 
0
4 
2 
207740  
86852   
92880 
180984    
0 
0     
1200 
0      
654 
1505    
6 
7     
87 
0
6 
1 
207740  
85736   
93996 
180984    
0 
0     
1116 
0      
526 
1512    
5 
10    
85 
0
0 
1 
207740  
84844   
94888 
180984    
0 
0     
892 
0       
438 
1556    
6 
4     
90 
0

从这个case可以得出下面结论:

  1. 线程上线文切换相比中断要频繁,内核消耗大量的时间完成上下文切换。
  2. CPU负载严重不均衡,用户进程消耗很少的CPU,但是大量的时间都在等待IO
  3. 因为CPU在等待IO,导致有些任务被block住了

2.3,mpstat使用

因为现在大多服务器都是多核,可以采用mpstat命令查看每个单核CPU的使用情况

sankuai
@mobile
-moviesolr02:~$ mpstat -P ALL 
1
Linux 
3.2
.
0
-
34
-virtual (mobile-moviesolr02)     
10
/
16
/
2015  
_x86_64_    (
4 
CPU)
05
:
35
:
41 
PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
05
:
35
:
42 
PM  all   
25.81    
0.00    
1.25    
0.50    
0.00    
0.00    
0.00    
0.00   
72.43
05
:
35
:
42 
PM    
0    
1.00    
0.00    
1.00    
0.00    
0.00    
0.00    
0.00    
0.00   
98.00
05
:
35
:
42 
PM    
1   
35.71    
0.00    
0.00    
0.00    
0.00    
0.00    
0.00    
0.00   
64.29
05
:
35
:
42 
PM    
2    
6.93    
0.00    
3.96    
0.00    
0.00    
0.00    
0.00    
0.00   
89.11
05
:
35
:
42 
PM    
3   
59.41    
0.00    
0.99    
0.99    
0.00    
0.00    
0.00    
0.00   
38.61
 
05
:
35
:
42 
PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
05
:
35
:
43 
PM  all   
25.81    
0.00    
1.25    
0.00    
0.00    
0.00    
0.25    
0.00   
72.68
05
:
35
:
43 
PM    
0    
0.00    
0.00    
1.01    
0.00    
0.00    
0.00    
0.00    
0.00   
98.99
05
:
35
:
43 
PM    
1    
0.99    
0.00    
1.98    
0.00    
0.00    
0.00    
0.00    
0.00   
97.03
05
:
35
:
43 
PM    
2    
8.00    
0.00    
2.00    
0.00    
0.00    
0.00    
0.00    
0.00   
90.00
05
:
35
:
43 
PM    
3   
95.92    
0.00    
0.00    
0.00    
0.00    
0.00    
0.00    
0.00    
4.08

case 1:

#通过top -d 
1 
可以找出消耗CPU的大户
PID     USER PR NI VIRT RES SHR S %CPU %MEM TIME+       COMMAND
15957 
nobody 
25 
0 
2776 
280 
224  

100   
20.5 
0
:
25.48    
php
15959 
mysql  
25 
0 
2256 
280 
224  

100   
38.2 
0
:
17.78    
mysqld
15960 
apache 
25 
0 
2416 
280 
224  

100   
15.7 
0
:
11.20    
httpd
15901   
root 
16 
0 
2780 
1092 
800 

1     
0.1 
0
:
01.59     
top
1       
root 
16 
0 
1780 
660 
572  

0     
0.0 
0
:
00.64     
init
 
##然后可以看该进程在哪颗CPU上面,以及优先级如何
while 
:; 
do 
ps -eo pid,ni,pri,pcpu,psr,comm | grep 
'java'
; sleep 
1
; done
 
PID     NI      PRI     %CPU PSR COMMAND
15775   
0       
15      
86.0 
3 
mysqld
PID     NI      PRI     %CPU PSR COMMAND
15775   
0       
14      
94.0 
3 
mysqld
PID     NI      PRI     %CPU PSR COMMAND
15775   
0       
14      
96.6 
3 
mysqld
PID     NI      PRI     %CPU PSR COMMAND
15775   
0       
14      
98.0 
3 
mysqld
##PSR表示运行于第几颗CPU

 

参考:

  1. Linux调度器详解:https://www.ibm.com/developerworks/cn/linux/l-scheduler/

 

 
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/167721.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号