Linux性能监控-阿里云开发者社区

转自 http://hi.baidu.com/ccex/blog/item/f613f9d3d5e401d6a8ec9af8.html

Linux性能监控

Linux性能监控之绪论篇性能调优的目的是找到系统的瓶颈,并且调节系统来设法消除这些瓶颈．我们在监控性能的时候重点在于监视一下子系统：
１．ＣＰＵ
２．Ｍｅｍｏｒｙ
３．ＩＯ
４．Ｎｅｔｗｏｒｋ

但这些系统都是彼此依赖,不能单独只看其中一个.当一个系统负载过重时往往会引起其它子系统的问题,比如说:
->大量的读入内存的IO请求(page-in IO)会用完内存队列;
->大量的网络流量会造成CPU的过载;
->CPU的高使用率可能正在处理空闲内存队列;
->大量的磁盘读写会消耗CPU和IO资源.

我们测试的系统,总的来说可分为二类:
第一, IO Bound, 这类系统会大量消耗内存和底层的存储系统,它并不消耗过多的CPU和网络资源(除非系统是网络的).IO bound系统消耗CPU资源用来接受IO请求,然后会进入休眠状态. 数据库通常被认为是IO bound系统.

第二, CPU Bound,这类系统需要消耗大量的CPU资源.他们往往进行大量的数学计算. 高吞吐量的Web server, Mail Server通常被认为是CPU Bound系统.

在性能测试中首先要做的是建立基线(Baseline),这样后续的调整才会有一个参考标准.值得注意的是,在测试基线的时候,一定要保证系统工作在正常的状态下.

在Linux上,监视系统的性能的常用工具有:
Tool     Description                                      Base                      Repository
vmstat all purpose performance tool          yes                               yes
mpstat provides statistics per CPU             no                               yes
sar all purpose performance monitoring tool no                               yes
iostat provides disk statistics                      no                               yes
netstat provides network statistics                 yes                            yes
dstat monitoring statistics aggregator          no                   in most distributions
iptraf traffic monitoring dashboard                 no                                yes
ethtool reports on Ethernet interface configuration yes yes

这些工具在Linux的安装过程中都可以选择进行安装。

下面是一个vmstat产生的baseline的例子：
# 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

CPU篇

正如我们之前讨论的任何系统的性能比较都是基于基线的，并且监控CPU的性能就是以上3点，运行队列、CPU使用率和上下文切换。以下是一些对于CPU很普遍的性能要求：
1. 对于每一个CPU来说运行队列不要超过3，例如，如果是双核CPU就不要超过6；
2. 如果CPU在满负荷运行，应该符合下列分布，
a) User Time：65%～70%
b) System Time：30%～35%
c) Idle：0%～5%
3. 对于上下文切换要结合CPU使用率来看，如果CPU使用满足上述分布，大量的上下文切换也是可以接受的。

常用的监视工具有，vmstat, top,dstat和mpstat.
# 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表示运行队列的大小，
b表示由于IO等待而block的线程数量，
in表示中断的数量，
cs表示上下文切换的数量，
us表示用户CPU时间，
sys表示系统CPU时间，
wa表示由于IO等待而是CPU处于idle状态的时间，
id表示CPU处于idle状态的总时间。

dstat可以给出每一个设备产生的中断数：
# dstat -cip 1
----total-cpu-usage---- ----interrupts--- ---procs---
usr sys idl wai hiq siq| 15 169 185 |run blk new
6    1    91    2    0   0| 12    0 13 | 0 0 0
1    0    99    0    0   0| 0     0 6   | 0 0 0
0    0    100   0    0   0| 18    0 2   | 0 0 0
0    0    100   0    0   0| 0     0 3   | 0 0 0
我们可以看到这里有3个设备号15，169和185.设备名和设备号的关系我们可以参考文件/proc/interrupts, 这里185代表网卡eth1.
# cat /proc/interrupts
CPU0
0: 1277238713 IO-APIC-edge timer
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 1 IO-APIC-level acpi
14: 6011913 IO-APIC-edge ide0
15: 15761438 IO-APIC-edge ide1
169: 26 IO-APIC-level Intel 82801BA-ICH2
185: 16785489 IO-APIC-level eth1
193: 0 IO-APIC-level uhci_hcd:usb1

mpstat可以显示每个CPU的运行状况，比如系统有4个CPU。我们可以看到：
# 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

总结的说，CPU性能监控包含以下方面：
检查系统的运行队列，确保每一个CPU的运行队列不大于3.
确保CPU使用分布满足70/30原则（用户70%，系统30%）。
如果系统时间过长，可能是因为频繁的调度和改变优先级。
CPU Bound进程总是会被惩罚（降低优先级）而IO Bound进程总会被奖励（提高优先级）。

Memory篇

首先说说虚拟内存和物理内存：

虚拟内存就是采用硬盘来对物理内存进行扩展，将暂时不用的内存页写到硬盘上而腾出更多的物理内存让有需要的进程来用。当这些内存页需要用的时候在从硬盘读回内存。这一切对于用户来说是透明的。通常在Linux系统说，虚拟内存就是swap分区。在X86系统上虚拟内存被分为大小为4K的页。

每一个进程启动时都会向系统申请虚拟内存（VSZ），内核同意或者拒就请求。当程序真正用到内存时，系统就它映射到物理内存。RSS表示程序所占的物理内存的大小。用ps命令我们可以看到进程占用的VSZ和RSS。

# ps –aux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

daemon 2177 0.0 0.2 3352 648 ? Ss 23:03 0:00 /usr/sbin/atd

dbus 2196 0.0 0.5 13180 1320 ? Ssl 23:03 0:00 dbus-daemon-1 --sys

root 2210 0.0 0.4 2740 1044 ? Ss 23:03 0:00 cups-config-daemon

root 2221 0.3 1.5 6108 4036 ? Ss 23:03 0:02 hald

root 2231 0.0 0.1 2464 408 tty1 Ss+ 23:03 0:00 /sbin/mingetty tty1

内核会定期将内存中的数据同步到硬盘，这个过程叫做Memory Paging。同时内核也要负责回收不用的内存，将他们分给其他需要的进程。PFRA算法（Page Frame. reclaim algorithm）负责回收空闲的内存。算法根据内存页的类型来决定要释放的内存页。有下列4种类型：

1． Unreclaimable – 锁定的，内核保留的页面；

2． Swappable – 匿名的内存页；

3． Syncable – 通过硬盘文件备份的内存页；

4． Discardable – 静态页和被丢弃的页。

除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收。与之相关的进程是kswapd。在kswapd中，有2个阀值， pages_hige和pages_low。当空闲内存页的数量低于pages_low的时候，kswapd进程就会扫描内存并且每次释放出32个 free pages，直到free page的数量到达pages_high。具体kswapd是如何回收内存的呢？有如下原则：

1. 如果页未经更改就将该页放入空闲队列；

2. 如果页已经更改并且是可备份回文件系统的，就理解将内存页的内容写回磁盘；

3. 如果页已经更改但是没有任何磁盘上的备份，就将其写入swap分区。

# ps -ef | grep kswapd

root 30 1 0 23:01 ? 00:00:00 [kswapd0]

在回收内存过程中还有两个重要的方法，一是LMR（Low on memory reclaiming），另一个是OMK(Out of Memory Killer)。当分配内存失败的时候LMR将会其作用，失败的原因是kswapd不能提供足够的空闲内存，这个时候LMR会每次释放1024个垃圾页知道内存分配成功。当LMR不能快速释放内存的时候，OMK就开始其作用，OMK会采用一个选择算法来决定杀死某些进程。当选定进程时，就会发送信号 SIGKILL，这就会使内存立即被释放。OMK选择进程的方法如下：

1. 进程占用大量的内存；

2. 进程只会损失少量工作；

3. 进程具有低的静态优先级；

4. 进程不属于root用户。

进程管理中另一个程序pdflush用于将内存中的内容和文件系统进行同步，比如说，当一个文件在内存中进行修改，pdflush负责将它写回硬盘。

# ps -ef | grep pdflush

root 28 3 0 23:01 ? 00:00:00 [pdflush]

root 29 3 0 23:01 ? 00:00:00 [pdflush]

每当内存中的垃圾页（dirty page）超过10%的时候，pdflush就会将这些页面备份回硬盘。这个比率是可以调节的，通过参数vm.dirty_background_ratio。

# sysctl -n vm.dirty_background_ratio

Pdflush同PFRA是独立运行的，当内核调用LMR时，LMR就触发pdflush将垃圾页写回硬盘

IO篇

接下来我们分析一些具体的情况，在这些情况下I/O会成为系统的瓶颈。我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映除系统的性能情况。

情况1：同一时间进行大量的I/O操作

在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。

# vmstat 1

procs -----memory----- ---swap---io---- --system--cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57

2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52

2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52

从这个输出我们可以看到CPU有50%的时间都在等待I/O操作，我们还可以看到系统的bi值很大，证明系统有大量的I/O请求将磁盘内容读入内存。

没有很好的工具能看到到底是哪个进程在进行I/O读写。但我们可以通过top命令的输出来猜测

# top -d 1

top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40

Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie

Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si

Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers

Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND

3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx

3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx

3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx

3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx

将top的输出通过faults进行排序。我们可以看到vmware产生最多的page faults。也就是说它进行了大量的IO操作。

情况2：管道太小

任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000.

RPS=RPM/60=166

1/166=0.0006=6ms 磁盘旋转一周要6毫秒

RD=6ms/2=3ms

磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是：

3ms+3ms+2ms=8ms

IOPS=1000/8=125 这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。

对与系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。

连续I/O常常出现在企业级数据库这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢。我们用iostat来监控，会发现rKB/s,wKB/s会很高。

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00

从输出我们看到w/s=105,wKB/s=53040.所以53040/105=505KB per I/O.

对于随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数：

# iostat -x 1

avg-cpu: %user %nice %sys %idle

2.04 0.00 97.96 0.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00

从输出我们看到w/s=102,wKB/s=2640.所以2640/102=23KB per I/O.

因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值.

Network篇

网络是所有子系统中最难监控的了。首先是由于网络是抽象的，更重要的是许多影响网络的因素并不在我们的控制范围之内。这些因素包括，延迟、冲突、阻塞等等。

大部分的以太网络都是自适应速度的，因为一个网络中可能有不同的网络设备采用不同的速率和工作模式（全双工或半双工）。大部分企业网络都工作在100到1000BaseTX。ethtool命令可以设置网卡的工作速率和模式。

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

我们可以看到网卡工作在10Mb/s，模式为半双工，并且打开了自适应开关。我们通过下列命令强制设置网卡工作在100Mb/s全双工模式，并关闭自适应功能。

# ethtool -s eth0 speed 100 duplex full autoneg off

再次运行ethtool显示如下：

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

用iptraf工具可以清楚的看到每个网卡的工作情况。

# iptraf –d eth0

利用iptraf还可以监听固定TCP端口的流量，如对于Web服务器我们希望监听80端口的流量，对于邮件服务器我们关注25端口的流量。

网络中最常见的错误就是冲突，由于网络中目前基本采用交换机环境，因此冲突问题已被消除。但是当网络流量不断增大的时候，就会出现丢包，网卡过载等情况。在网络流量很大的时候我们用sar命令来给出网络中可能的错误:

# sar -n FULL 5 100
Linux 2.6.9-55.ELsmp (sapulpa) 06/23/2007
11:44:32 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
11:44:37 AM lo 6.00 6.00 424.40 424.40 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
11:44:37 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM totsck tcpsck udpsck rawsck ip-frag
11:44:37 AM 297 79 8 0 0

rxerr/s是接受错误率；txerr/s是发送错误率；coll/s冲突率；rxdrop/s接受帧丢失率；txdrop/s发送帧丢失率； txcarr/s载波错误率；rxfram/s帧排列错误；rxfifo/s接受FIFO错误；txfifo/s发送FIFO错误。从上面输出看出各种错误为零，证明网络工作良好。

总的来说监视网络性能，我们有遵循一下几点：

1. 检查所有网络接口确保他们都运行在正确的速率；

2. 检查每块网卡的吞吐量确保没有造成过载；

3. 检查流量的类型确保正确的数据流在传送。

Linux性能监控

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像