CPU性能监测介绍
CPU的性能监测包含以下部分:
* 检查系统运行队列并确保每个核心上不超过3个可运行进程
* 确保CPU利用率的用户时间和系统时间在70/30之间
* 当CPU花费更多的时间在system mode上时,更有可能是因过载而试图重新调度优先级
* 运行CPU限制型应用比IO限制型应用更易出现性能瓶颈
性能调优是找出系统瓶颈并消除这些瓶颈的过程。很多系统管理员认为性能调优仅仅是调整一下内核的参数即可解决问题,事实上情况并不是这样。性能调优是实现操作系统的各个子系统之间的平衡性,这些子系统包括:
* CPU
* Memory
* IO
* Network
子系统之间相互依存,任何一个子系统的负载过度都能导致其他子系统出现问题,例如:
* 大量的page-in IO 请求可能导致内存队列被塞满
* 网卡的巨量吞吐可能导致CPU资源耗尽
* 系统尝试保持释放内存队列时可能耗尽CPU资源
* 来自内存的大量磁盘写入请求可能导致CPU资源和IO通道耗尽
性能调优的前提是找出系统瓶颈之所在,尽管问题看似由某个子系统所导致,然而这很可能是另外一个子系统的过载所引起的。
判定应用的类型
为了明白从何处开始着手调整性能瓶颈,弄清被分析系统的性能表现是首要任务。任何系统的应用常可分为以下两类:
* IO限制型——一个IO限制型的应用需要大量的内存和基础存储设备占用。因其需要大量的数据读写请求,此类应用对CPU和网络需求不高(除非存储系统在网络上)。IO限制型应用使用CPU资源来进行IO操作且常进入睡眠状态。数据库应用常被认为属于此类。
* CPU限制型——一个CPU限制型应用需要大量的CPU资源,来进行批量的处理或大量的计算。大容量web服务,mail服务,以及任何类型的渲染服务都被归到此类。
判定基准信息
系统的利用率因管理员的期望值和系统的参数值而异,判断一个系统是否有性能问题的唯一途径是弄清楚对系统的期望是神马,需求的性能是神马,应该得到的数据是神马?而为了建立这些信息的唯一途径是为系统建立一个基准。在性能可接受的状态下必须为系统建立统计信息,这样就可以在性能不可接受时进行对比。
在下面的例子中,将对两种状态下的统计信息进行对比:
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99
0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45
0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100
0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80
0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75
1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72
0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79
# 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 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96
2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0
3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0
2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0
2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0
2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0
2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0
2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0
2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0
只需要看代表idle时间的最后一列(id)就能发现问题,在基准数据中CPU空闲时间在79%-100%之间,在高负荷状态下系统利用率100%且无空闲。需要考虑的是CPU这块的问题。
安装监测工具
大多*nix系统均自带了很多标准监测命令,也有的是第三方工具:
工具名称 描述 基础安装包 可选安装包
vmstat 多功能 Y Y
mpstat CPU性能 N Y
sar 多功能 N Y
iostat 磁盘性能 N Y
netstat 网络性能 Y Y
dstat 多功能 N 大多数
iptraf 流量监测 N Y
netperf 网络带宽 N 大多数
ethtool 网卡监测 Y Y
iperf 网络带宽 N Y
tcptrace 数据包监测 N Y
iotop IO监测 N Y
CPU介绍
CPU利用率很大部分取决于试图访问它的资源,内核拥有一个管理两种资源的调度器:
线程(单或多)和中断。调度器给予不同资源以不同的优先级,以下由优先级从高到低:
* 中断——设备通知内核它们处理完成。例如网卡发送一个数据包或硬盘驱动器提供一次IO请求
* 内核(系统)进程——所有的内核进程都在此级别的优先级进行处理
* 用户进程——通常被称为“用户空间”,所有应用软件运行在用户空间,拥有最低的优先级
为了弄明白内核是如何管理不同的资源的,几个关键概念需要提及一下:context switches,run queues,utilization。
Context Switches(上下文切换)
大多数处理器在同一时间只能处理一个进程或线程,多线程处理器可同时处理n个线程。然而,linux内核把多核处理器的各个核心当做独立核心。例如,内核把一个双核的处理当做两个独立处理器。
一个标准的内核可同时处理50到50000个进程,在只有一颗CPU的情况下,内核必须调度和平衡这些进程和线程。每个线程在处理器上都拥有一个时间分配单元,当一个线程超过自己的时间单元或被更高优先级的程序抢占时,此线程及被传回队列而此时更高优先级的程序将在处理器上执行。这种线程间的切换操作即是上下文切换。
运行队列
每个CPU维持着一个线程的运行队列,理论上,调度器应该是不断地运行和执行线程。线程要么处于睡眠状态,要么处于可运行状态。假如CPU子系统处于高负载状态,那么内核调度器罢工是有可能的,其结果将导致可运行状态的进程开始阻塞运行队列。运行队列越大,执行进程所花费的时间也越长。
一个很流行的术语叫“load(负载)”经常被用来描述运行队列的状态,系统负载是由正在执行的进程和CPU运行队列中的进程的结合,如果有2个线程正在一个双核系统中执行且4个正在运行队列中,那么负载数即是6,像top等工具可查看过去1,5,15分钟的负载均值。
CPU利用率
CPU利用率被定义为CPU使用的百分比,CPU如何被利用是衡量一个系统的重要标准。多数性能监测工具把CPU利用分为以下几个类型:
* 用户时间——CPU花在执行用户空间进程的时间百分比
* 系统时间——CPU花在执行内核进程和中断的时间百分比
* IO等待——CPU花在等待IO请求完成的时间百分比
* IDLE——CPU的空闲时间百分比
CPU性能监测
理解CPU的性能状态即是理解中断,运行队列和上下文切换的状态。之前有提到过性能与基准信息有密切关系,但是有些常规的性能预期:
* 运行队列——每个处理器上的运行队列不应该有超过1-3个排队的线程。例如,一个双核系统不应该有超过6个进行在运行队列里。
* CPU利用率——假如一个CPU满状态负荷,那么以下的平衡关系需要达到:
65%--70%的用户时间
30%--35%的系统时间
0%--5%的空闲时间
* 上下文切换——上下文切换的数量与CPU的利用率有直接关系。如果CPU处于高负荷状态下那么大量的上下文切换是正常的。
linux系统里有很多可以监测以上数据的工具,如vmstat和top。
vmstat工具的使用
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
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
每个区域的含义:
区域 描述
r run queue 运行队列中的进程数
b blocked 等待IO请求完成的阻塞进程数
in interrupts 正在处理的中断数
cs context switches 正在发生的上下文切换数
us user 用户CPU时间百分比
sys system 内核CPU时间百分比
wa wait 可运行进程等待IO百分比
id idle CPU空闲时间百分比
案例分析:CPU持续性利用
# 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
可从数据得到如下观察结果:
* 其拥有很高的中断数(in)和很低的上下文切换数,这说明可能有单个进程在进行大量的硬件资源请求。
* 用户时间平均在85%以上,说明此进程一直停留在处理器中。
* 运行队列数刚好达到可接受的上限值,且出现超过上限值的情况。
案例分析:超载调度
以下示例中内核调度器的上下文切换达到饱和:
# 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
可从数据得到如下观察结果:
* 上下文切换数高于中断数,这表明内核必须花费相当数量的时间来处理上下文切换进程。
* 大量的上下文切换引起CPU利用的不平衡,明显的事实是大量的IO等待和用户时间的不足。
* 由于CPU受IO等待的限制,运行队列开始阻塞。
mpstat工具的使用
如果你的系统有多个处理器核心,你就可以使用mpstat工具来监测每个核心。linux内核把一个双核处理器当做2个CPU,所以一个拥有2颗双核心的系统将被视为4CPU。
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
案例分析:未过载状态
下面的案例中有4个CPU:
# top -d 1
top - 23:08:53 up 8:34, 3 users, load average: 0.91, 0.37, 0.13
Tasks: 190 total, 4 running, 186 sleeping, 0 stopped, 0 zombie
Cpu(s): 75.2% us, 0.2% sy, 0.0% ni, 24.5% id, 0.0% wa, 0.0% hi, 0.0%
si
Mem: 2074736k total, 448684k used, 1626052k free, 73756k buffers
Swap: 4192956k total, 0k used, 4192956k free, 259044k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15957 nobody 25 0 2776 280 224 R 100 20.5 0:25.48 php
15959 MySQL 25 0 2256 280 224 R 100 38.2 0:17.78 mysqld
15960 apache 25 0 2416 280 224 R 100 15.7 0:11.20 httpd
15901 root 16 0 2780 1092 800 R 1 0.1 0:01.59 top
1 root 16 0 1780 660 572 S 0 0.0 0:00.64 init
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 81.52 0.00 18.48 21.17 130.58
05:17:32 PM 0 83.67 0.00 17.35 0.00 115.31
05:17:32 PM 1 80.61 0.00 19.39 0.00 13.27
05:17:32 PM 2 0.00 0.00 16.33 84.66 2.01
05:17:32 PM 3 79.59 0.00 21.43 0.00 0.00
05:17:32 PM CPU %user %nice %system %idle intr/s
05:17:33 PM all 85.86 0.00 14.14 25.00 116.49
05:17:33 PM 0 88.66 0.00 12.37 0.00 116.49
05:17:33 PM 1 80.41 0.00 19.59 0.00 0.00
05:17:33 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:33 PM 3 83.51 0.00 16.49 0.00 0.00
05:17:33 PM CPU %user %nice %system %idle intr/s
05:17:34 PM all 82.74 0.00 17.26 25.00 115.31
05:17:34 PM 0 85.71 0.00 13.27 0.00 115.31
05:17:34 PM 1 78.57 0.00 21.43 0.00 0.00
05:17:34 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:34 PM 3 92.86 0.00 9.18 0.00 0.00
05:17:34 PM CPU %user %nice %system %idle intr/s
05:17:35 PM all 87.50 0.00 12.50 25.00 115.31
05:17:35 PM 0 91.84 0.00 8.16 0.00 114.29
05:17:35 PM 1 90.82 0.00 10.20 0.00 1.02
05:17:35 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:35 PM 3 81.63 0.00 15.31 0.00 0.00
你可以使用ps命令判定哪个进程运行在哪个CPU上:
# while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'mysqld'; 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
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.8 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 99.3 3 mysqld
CPU性能监测介绍的更多相关文章
- JMeter性能监测插件介绍(三)
JMeter 性能监测插件介绍 压力测试过程中,能够随时对负载服务器的健康状况的把控是相当重要的,有了这些数据,我们才能准确分析出服务器负载瓶颈.JMeter 插件包现在能够支持服务器监控,可以在所有 ...
- Linux按照CPU、内存、磁盘IO、网络性能监测
系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书 ...
- Linux 性能监测:介绍
看了某某教程.读了某某手册,按照要求改改某某设置.系统设定.内核参数就认为做到系统优化的想法很傻很天真:)系统优化是一项复杂.繁琐.长期的 工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采 ...
- inux按照CPU、内存、磁盘IO、网络性能监测
http://my.oschina.net/chape/blog/159640 系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长 ...
- Linux性能监测:CPU篇(转)
http://os.51cto.com/art/201012/239880.htm CPU 的占用主要取决于什么样的资源正在 CPU 上面运行,比如拷贝一个文件通常占用较少 CPU,因为大部分工作是由 ...
- Linux 性能监测:CPU
CPU 的占用主要取决于什么样的资源正在 CPU 上面运行,比如拷贝一个文件通常占用较少 CPU,因为大部分工作是由 DMA(Direct Memory Access)完成,只是在完成拷贝以后给一个中 ...
- PHP性能监测的工具介绍 - XHProf -参考自https://jingyan.baidu.com/article/7082dc1c173359e40a89bd95.html
XHProf 这个软件本是Facebook内部的一个应用工具,2009年3月份开源,为PHP的性能监测提供了很好的工具.官方的介绍中提到: 方法/步骤 XHProf 这个软件本是Faceboo ...
- Linux按照CPU、内存、磁盘IO、网络性能监测【转载】
本文转载地址:https://my.oschina.net/chape/blog/159640 系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监 ...
- Linux性能监测:CPU篇
CPU 也是一种硬件资源,和任何其他硬件设备一样也需要驱动和管理程序才能使用,我们可以把内核的进程调度看作是 CPU 的管理程序,用来管理和分配 CPU 资源,合理安排进程抢占 CPU,并决定哪个进程 ...
随机推荐
- 自学Python5.5-面向对象三大基本特征_继承
自学Python之路-Python基础+模块+面向对象自学Python之路-Python网络编程自学Python之路-Python并发编程+数据库+前端自学Python之路-django 自学Pyth ...
- 转(static final 和final的区别)
学习java的时候常常会被修饰符搞糊涂,这里总结下static final和final的区别. 1.static 强调只有一份,final 说明是一个常量,final定义的基本类型的值是不可改变的,但 ...
- 去掉或修改lightinthebox网址与标题中Wholesale关键词
includes\languages\english.php define('SEO_COMMON_KEYWORDS','Wholesale'); 将里面的Wholesale换成你想显示的词即可.
- 基于Redis实现分布式锁(转载)
原文地址:http://blog.csdn.net/ugg/article/details/41894947 Redis命令介绍使用Redis实现分布式锁,有两个重要函数需要介绍 SETNX命令(SE ...
- list实现栈以及队列操作
1.堆栈stack操作:尾进 尾出 或者叫先进后出 //1借助LinkedList 类中的方法实现栈 public class MyStack { private LinkedList<Obje ...
- CentOS 7 安装 metasploit-framework
1 一键安装metasploit-framework apt-get install curl,wgetcurl https://raw.githubusercontent.com/rapid7/me ...
- Java & Mysql 餐饮管理系统 过程心得记录
------------------------------------------Have a Good Day~---------------------------------- 准备国赛和AC ...
- DevExpress ASP.NET v19.1版本亮点:发布全新的Gantt控件
行业领先的.NET界面控件DevExpress 发布了v19.1版本,本文将以系列文章的方式为大家介绍DevExpress ASP.NET Controls v19.1中新增的一些控件及增强的控件功能 ...
- Mysql数据同步Elasticsearch方案总结
Mysql数据同步Elasticsearch方案总结 https://my.oschina.net/u/4000872/blog/2252620
- CSS3背景定位 background-origin
background-size 大小 语法 background-size :[ <length> | <percentage> | auto ]{1,2} | cover | ...