Linux System and Performance Monitoring(CPU篇)

时间 2019-11-29

标签 linux system performance monitoring cpu 栏目 Linux 繁體版

原文原文链接

1.0 性能监控介绍php

性能优化就是找到系统处理中的瓶颈以及去除这些的过程,多数管理员相信看一些相关的”cook book”就能够实现性能优化,一般经过对内核的一些配置是能够简单的解决问题,但并不适合每一个环境,性能优化实际上是对OS 各子系统达到一种平衡的定义,这些子系统包括了:mysql

CPU
Memory
IO
Networkios

这些子系统之间关系是相互彼此依赖的,任何一个高负载都会致使其余子系统出现问题.好比:web

大量的页调入请求致使内存队列的拥塞
网卡的大吞吐量可能致使更多的 CPU开销
大量的CPU开销又会尝试更多的内存使用请求
大量来自内存的磁盘写请求可能致使更多的 CPU 以及 IO问题
因此要对一个系统进行优化,查找瓶颈来自哪一个方面是关键,虽然看似是某一个子系统出现问题,其实有多是别的子系统致使的.sql

1.1 肯定应用类型数据库

基于须要理解该从什么地方来入手优化瓶颈,首先重要的一点,就是理解并分析当前系统的特色,多数系统所跑的应用类型,主要为2种:apache

IO Bound(译注:IO 范畴): 在这个范畴中的应用,通常都是高负荷的内存使用以及存储系统,这实际上表示IO 范畴的应用,就是一个大量数据处理的过程.IO 范畴的应用不对CPU以及网络发起更多请求(除非相似NAS这样的网络存储硬件).IO 范畴的应用一般使用CPU 资源都是为了产生IO 请求以及进入到内核调度的sleep 状态.一般数据库软件(译注:mysql,oracle等)被认为是IO 范畴的应用类型.性能优化

CPU Bound(译注:CPU 范畴): 在这个范畴中的应用,通常都是高负荷的CPU 占用. CPU 范畴的应用,就是一个批量处理CPU 请求以及数学计算的过程.一般web server,mail server,以及其余类型服务被认为是CPU 范畴的应用类型.bash

1.2 肯定基准线统计服务器

系统利用率状况,通常随管理员经验以及系统自己用途来决定.惟一要清楚的就是,系统优化但愿达成什么效果,以及哪些方面是须要优化,还有参考值是什么?所以就创建一个基准线,这个统计数据必须是系统可用性能状态值,用来比较不可用性能状态值.

在如下例子中,1个系统性能的基准线快照,用来比较当高负荷时的系统性能快照.

[root @opt-001 ~ ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 91 239 3047 0 0 4 55 32 20 1 1 98 0 0
0 0 0 92 239 3047 0 0 0 0 1127 3131 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1105 3064 0 0 100 0 0
0 0 0 92 239 3047 0 0 4 0 1156 3071 1 1 99 0 0
0 0 0 92 239 3047 0 0 0 604 1177 2976 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1082 3018 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 16 1075 3023 0 0 99 1 0
2 0 0 92 239 3047 0 0 0 56 1101 3134 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1041 3040 0 0 100 0 0

[root @opt-001 ~ ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 710 113 2573 0 0 4 55 0 20 1 1 98 0 0
2 0 0 701 113 2582 0 0 4192 0 1175 4754 24 1 75 1 0
2 0 0 694 113 2590 0 0 3584 21012 1470 4323 16 1 61 22 0
2 0 0 684 113 2598 0 0 4272 572 1167 4813 23 1 75 2 0
3 0 0 676 113 2606 0 0 3832 0 1211 5168 25 1 75 0 0
2 0 0 671 113 2610 0 0 1336 0 1061 4230 24 0 75 0 0
2 0 0 664 113 2618 0 0 2916 0 1168 5368 24 1 74 1 0
2 0 0 658 113 2623 0 0 0 20228 1099 5656 24 1 68 7 0
2 0 0 654 113 2628 0 0 0 0 1048 5275 24 1 75 0 0
2 0 0 649 113 2633 0 0 4 0 1075 5681 25 1 73 0 0
2 0 0 644 113 2638 0 0 0 0 1066 5257 25 1 75 0 0
2 0 0 637 113 2645 0 0 1432 0 1050 5462 24 1 75 1 0
5 0 0 628 113 2654 0 0 4348 24840 1240 5301 23 2 70 6 0

从上面第一个结果可看到,最后一列(id) 表示的是空闲时间,咱们能够看到,在基准线统计时,CPU 的空闲时间在98% - 100%.在第二个结果可看到,系统处于60%~70%的占用率。从这个比较中,咱们就能够肯定是不是CPU 使用率应该被优化.

2.0 安装监控工具

多数 *nix系统都有一堆标准的监控命令.这些命令从一开始就是*nix 的一部分.Linux 则经过基本安装包以及额外包提供了其余监控工具,这些安装包多数都存在各个Linux 发布版本中.尽管还有其余更多的开源以及第三方监控软件,但本文档只讨论基于Linux 发布版本的监控工具.

本章将讨论哪些工具怎样来监控系统性能.

Tool	描述	系统自带	扩展包
vmstat	通用的性能监控工具	yes	yes
mpstat	提供每一个cpu的统计信息	no	yes
sar	通用的性能监控工具	no	yes
iostat	提供磁盘统计	no	yes
netstat	提供网络统计	yes	yes
dstat	统计监控汇总	no	大多数发行版
iptraf	网络流量监控	no	yes
netperf	网络带宽工具	no	大多数发行版
ethtool	网卡配置显示工具	yes	yes
iperf	网络带宽公积金	no	yes
tcptrace	网络包分析工具	no	yes

3.0 CPU 介绍

CPU 利用率主要依赖因而什么资源在试图存取.内核调度器将负责调度2种资源种类:线程(单一或者多路)和中断.调度器去定义不一样资源的不一样优先权.如下列表从优先级高到低排列:

Interrupts(译注:中断) - 设备通知内核,他们完成一次数据处理的过程.例子,当一块网卡设备递送网络数据包或者一块硬件提供了一次IO 请求.

Kernel(System) Processes(译注:内核处理过程) - 全部内核处理过程就是控制优先级别.

User Processes(译注:用户进程) - 这块涉及”userland”.全部软件程序都运行在这个user space.这块在内核调度机制中处于低优先级.

从上面,咱们能够看出内核是怎样管理不一样资源的.还有几个关键内容须要介绍,如下部分就将介绍context(译注:上下文切换),run queues(译注:运行队列)以及utilization(译注:利用率).

3.1 上下文切换

多数现代处理器都可以运行一个进程(单一线程)或者线程.多路超线程处理器有能力运行多个线程.然而,Linux 内核仍是把每一个处理器核心的双核心芯片做为独立的处理器.好比,以Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.

一个标准的Linux 内核能够运行50 至 50,000 的处理线程.在只有一个CPU时,内核将调度并均衡每一个进程线程.每一个线程都分配一个在处理器中被开销的时间额度.一个线程要么就是得到时间额度或已抢先得到一些具备较高优先级(好比硬件中断),其中较高优先级的线程将从区域从新放置回处理器的队列中.这种线程的转换关系就是咱们提到的上下文切换.

每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将获得更多的工做.

3.2 运行队列

每一个CPU 都维护一个线程的运行队列.理论上,调度器应该不断的运行和执行线程.进程线程不是在sleep 状态中(译注:阻塞中和等待IO中)或就是在可运行状态中.若是CPU 子系统处于高负荷下,那就意味着内核调度将没法及时响应系统请求.致使结果,可运行状态进程拥塞在运行队列里.当运行队列愈来愈巨大,进程线程将花费更多的时间获取被执行.

比较流行的术语就是”load”,它提供当前运行队列的详细状态.系统 load 就是指在CPU 队列中有多少数目的线程,以及其中当前有多少进程线程数目被执行的组合.若是一个双核系统执行了2个线程,还有4个在运行队列中,则 load 应该为 6. top 这个程序里显示的load averages 是指1,5,15 分钟之内的load 状况.

3.3 CPU 利用率

CPU 利用率就是定义CPU 使用的百分比.评估系统最重要的一个度量方式就是CPU 的利用率.多数性能监控工具关于CPU 利用率的分类有如下几种:

User Time(译注:用户进程时间) - 关于在user space中被执行进程在CPU 开销时间百分比.

System Time(译注:内核线程以及中断时间) - 关于在kernel space中线程和中断在CPU 开销时间百分比.

Wait IO(译注:IO 请求等待时间) - 全部进程线程被阻塞等待完成一次IO 请求所占CPU 开销idle的时间百分比.

Idle(译注:空闲) - 一个完整空闲状态的进程在CPU 处理器中开销的时间百分比.

4.0 CPU 性能监控

理解运行队列,利用率,上下文切换对怎样CPU 性能最优化之间的关系.早期说起到,性能是相对于基准线数据的.在一些系统中,一般预期所达到的性能包括:

Run Queues - 每一个处理器应该运行队列不超过1-3 个线程.例子,一个双核处理器应该运行队列不要超过6 个线程.

CPU Utiliation - 若是一个CPU 被充分使用,利用率分类之间均衡的比例应该是
65% - 70% User Time
30% - 35% System Time
0% - 5% Idle Time

Context Switches - 上下文切换的数目直接关系到CPU 的使用率,若是CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.

不少Linux 上的工具能够获得这些状态值,首先就是 vmstat 和 top 这2个工具.

4.1 vmstat 工具的使用

vmstat 工具提供了一种低开销的系统性能观察方式.由于 vmstat 自己就是低开销工具,在很是高负荷的服务器上,你须要查看并监控系统的健康状况,在控制窗口仍是可以使用vmstat 输出结果.这个工具运行在2种模式下:average 和 sample 模式.sample 模式经过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,颇有帮助.下面就是

vmstat 运行1秒间隔的示例:

[root @opt-001 ~ ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 633 157 2618 0 0 4 54 12 23 1 1 98 0 0
1 0 0 633 157 2618 0 0 0 0 1062 3013 0 0 100 0 0
1 0 0 633 157 2618 0 0 0 0 1039 2924 0 0 100 0 0
1 0 0 633 157 2618 0 0 0 0 1041 3005 0 0 100 0 0

Table 1: The vmstat CPU statistics
Field          Description
r         The amount of threads in the run queue. These are threads that are runnable, but the CPU is not available to execute them.
当前运行队列中线程的数目.表明线程处于可运行状态,但CPU 还未能执行.
b          This is the number of processes blocked and waiting on IO requests to finish.
当前进程阻塞并等待IO 请求完成的数目
in          This is the number of interrupts being processed.
当前中断被处理的数目
cs          This is the number of context switches currently happening on the system.
当前kernel system中,发生上下文切换的数目
us          This is the percentage of user CPU utilization.
CPU 利用率的百分比
sys          This is the percentage of kernel and interrupts utilization.
内核和中断利用率的百分比
wa         This is the percentage of idle processor time due to the fact that ALL runnable threads are blocked waiting on IO.
全部可运行状态线程被阻塞在等待IO 请求的百分比
id          This is the percentage of time that the CPU is completely idle.
CPU 空闲时间的百分比

4.2 案例学习:持续的CPU 利用率

在这个例子中,这个系统被充分利用

[root @opt-001 ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
6 0 0 930 62 271 0 0 0 0 17818 35803 5 38 57 0 0
8 0 0 561 62 271 0 0 0 0 17645 34637 4 35 61 0 0
7 0 0 224 62 271 0 0 0 0 17837 32955 5 37 58 0 0
5 0 0 129 62 184 0 0 0 0 17903 29061 3 24 73 0 0
1 0 0 131 58 159 0 0 0 32 17855 21732 1 9 90 0 0
1 0 0 128 58 159 0 0 0 0 17579 18884 1 7 93 0 0
0 0 0 126 58 159 0 0 0 12 17598 18832 1 8 91 0 0
1 1 0 130 55 156 0 0 0 0 17553 18652 1 7 71 22 0

根据观察值,咱们能够获得如下结论:

1,有大量的中断(in) 和更多的的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备请求的同时发生了不少的上下文切换，这也不奇怪，当系统中装有多颗CPU或者1CPU多核时这种上下文的切换会更频繁。

2,进一步显示某单个应用,user time(us) 常常在10%或者更少.但sy的却占了不少的比例，说明内核花了不少的资源来进行上下文切换。能够得知系统中并发了不少程序。

3,运行队列中有4次超出了容许的范围，还有4次在容许的范围内。这个队列数应该控制在小于等于CPU核心数量。

4.3 案例学习:超负荷调度

在这个例子中,io等待时间占用不少比例的例子

[root @monitor ~ ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 3 53 55 53 1477 0 0 9 216 5 6 2 1 93 4 0
1 2 53 53 54 1474 0 0 92 29820 1195 2954 2 41 8 48 0
0 3 53 27 54 1387 0 0 0 950504 1237 10419 1 43 6 51 0
2 4 53 50 48 1369 0 0 0 123744 1172 297 0 7 0 93 0
0 5 53 50 40 1378 0 0 4 95996 1179 325 0 10 0 90 0
0 5 53 50 18 1400 0 0 0 104108 1150 301 0 9 0 91 0
0 5 53 48 10 1408 0 0 0 131272 1173 345 1 8 0 92 0
0 5 53 51 10 1406 0 0 4 89912 1161 249 0 7 0 94 0
0 5 53 50 9 1405 0 0 0 112952 1146 234 0 10 0 90 0

根据观察值,咱们能够获得如下结论:

1,某些时刻上下文切换数目高于中断数目,说明kernel中至关数量的时间都开销在上下文切换线程.

2,大量的上下文切换将致使CPU 利用率分类不均衡.很明显实际上等待io 请求的百分比(wa)很是高,以及user time百分比很是低(us).

3,由于CPU 都阻塞在IO请求上,因此运行队列里也有至关数目的可运行状态线程在等待执行.且还有阻塞线程

4.4 mpstat 工具的使用

若是你的系统运行在多处理器芯片上,你可使用 mpstat 命令来监控每一个独立的芯片.Linux 内核视双核处理器为2 CPU’s,所以一个双核处理器的双内核就报告有4 CPU’s 可用.

mpstat 命令给出的CPU 利用率统计值大体和 vmstat 一致,可是 mpstat 能够给出基于单个处理器的统计值.

[root @opt-001 ~ ] # mpstat -P ALL 1
Linux 2.6.18- 164.el5 (opt-001.jobkoo.com ) 09 / 25 / 2009

03: 12: 25 PM CPU %user % nice %sys %iowait %irq %soft %steal %idle intr /s
03: 12: 26 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1010.00
03: 12: 26 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1001.00
03: 12: 26 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
03: 12: 26 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1.00
03: 12: 26 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 7.00

4.5 案例学习: 未充分使用的处理量

在这个例子中,为4 CPU核心可用.其中2个CPU 主要处理进程运行(CPU 0 和1).第3个核心处理全部内核和其余系统功能(CPU 3).第4个核心处于idle(CPU 2).

使用 top 命令能够看到有3个进程差很少彻底占用了整个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 命令经过查看 PSR 这列,检查哪一个进程在占用了哪一个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

4.6 结论

监控 CPU 性能由如下几个部分组成:

1,检查system的运行队列,以及肯定不要超出每一个处理器3个可运行状态线程的限制.

2,肯定CPU 利用率中user/system比例维持在70/30

3,当CPU 开销更多的时间在system mode,那就说明已经超负荷而且应该尝试从新调度优先级

4,当I/O 处理获得增加,CPU 范畴的应用处理将受到影响