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

时间: 2024-09-30 04:16:50

CPU性能监测介绍的相关文章

Linux按照CPU、内存、磁盘IO、网络性能监测

目录[-] Linux性能监测:CPU篇 Linux性能监测:内存篇 Linux性能监测:磁盘IO篇 Linux性能监测:网络篇 系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的一环,如果没有监测

Linux按照CPU、内存、磁盘IO、网络性能监测【转载】

本文转载地址:https://my.oschina.net/chape/blog/159640 Linux按照CPU.内存.磁盘IO.网络性能监测 系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的

Linux 性能监测:介绍

看了某某教程.读了某某手册,按照要求改改某某设置.系统设定.内核参数就认为做到系统优化的想法很傻很天真:)系统优化是一项复杂.繁琐.长期的 工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不是说现在优化了,测试了,以后就可以一劳 永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同.优化的方法也不同.优化的参数也不同.性 能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里

Linux 性能监测:CPU

CPU 的占用主要取决于什么样的资源正在 CPU 上面运行,比如拷贝一个文件通常占用较少 CPU,因为大部分工作是由 DMA(Direct Memory Access)完成,只是在完成拷贝以后给一个中断让 CPU 知道拷贝已经完成:科学计算通常占用较多的 CPU,大部分计算工作都需要在 CPU 上完成,内存.硬盘等子系统只做暂时的数据存储工作.要想监测和理解 CPU 的性能需要知道一些操作系统的基本知识,比如:中断.进程调度.进程上下文切换.可运行队列等.这里 VPSee 用个例子来简单介绍一下

Linux 性能监测:工具

一个完整运行的 Linux 系统包括很多子系统(介绍,CPU,Memory,IO,Network,-),监测和评估这些子系统是性能监测的一部分.我们往往需要宏观的看整个系统状态,也需要微观的看每个子系统的运行情况.幸运的是,我们不必重复造轮子,监控这些子系统都有相应的工具可用,这些经过时间考验.随 Unix 成长起来.简单而优雅的小工具是我们日常 Unix/Linux 工作不可缺少的部分. 下面这张图片很好的总结了 Linux 各个子系统以及监控这些子系统所需要的工具,如果你对 Linux 系统

Linux性能监测(转载)

Linux性能监测 1.Linux性能监测:监测目的与工具介绍 看了某某教程.读了某某手册,按照要求改改某些设置.系统设定.内核参数就认为做到系统优化的想法很傻很天真:)系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同.优化的方法也不同.优化的参数也不同.性能监测是系

Linux主机性能监测

Linux主机作为服务器,在很多高并发的场景下,需要对系统参数进行优化来提升主机性能.而确认主机的性能瓶颈点在哪里就非常重要了,这里主要在以下几个方面进行说明: 1.CPU 2.内存 3.磁盘 4.网络 下面就这几个方面借助网友的经验,简单的总结一下.内容主要来自http://www.vpsee.com/ CPU的监测 在确定是否需要对系统进行优化时,我们首先需要确认系统CPU目前的负载状态.我们可以使用 vmstat命令来查看当前系统的负载. vmstat 工具提供了一种低开销的系统性能观察方

linux性能监测工具

cpu篇:CPU 也是一种硬件资源,和任何其他硬件设备一样也需要驱动和管理程序才能使用,我们可以把内核的进程调度看作是 CPU 的管理程序,用来管理和分配 CPU 资源,合理安排进程抢占 CPU,并决定哪个进程该使用 CPU.哪个进程该等待 要想监测和理解 CPU 的性能需要知道一些的操作系统的基本知识,比如:中断.进程调度.进程上下文切换.可运行 队列等.这里 VPSee 用个例子来简单介绍一下这些概念和他们的关系,CPU 很无辜,是个任劳任怨的打工仔,每时每 刻都有工作在做(进程.线程)并且

Linux 性能监测:Memory

这里的讲到的 “内存” 包括物理内存和虚拟内存,虚拟内存(Virtual Memory)把计算机的内存空间扩展到硬盘,物理内存(RAM)和硬盘的一部分空间(SWAP)组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间,好处是我们拥有的内存 ”变多了“,可以运行更多.更大的程序,坏处是把部分硬盘当内存用整体性能受到影响,硬盘读写速度要比内存慢几个数量级,并且 RAM 和 SWAP 之间的交换增加了系统的负担. 在操作系统里,虚拟内存被分成页,在 x86 系统上每个页大小是 4KB.Linu