《Ourlinux》杂志

终于拟出了监控特性规范，给自己鼓励下，明天继续完善:)

nmon for Linux 官方：http://nmon.sourceforge.net/pmwiki.php

下面是收集的资料：nmon工具介绍 (监控优化-操作系统监控)

{DNS}DNS劫持监控：检查根服务和授权域服务器。
比如：dig 51.com +trace

下个手机客户端，然后注册个pushme.to的帐号，比如：ourlinux，然后就可以通过pushme的接口进行发消息了。

HTML代码如下：

linux下简单的执行如下：

curl -o /dev/null -d “nickname=ourlinux&signature=OWL&submit=%20OK%20&&message=test” http://pushme.to/ourlinux/

记得将ourlinux改成自己的接收的账号！

这样就可以将报警的信息通过pushme来发送了！

其他的不说了，很简单，一看就明白了！

感谢joe推荐使用pushme！

正式将目前在开发的监控平台命名为：owl，中文为猫头鹰，正如猫头鹰敏锐的目光能快速准确的找到＂猎物＂

基于ganglia为核心的监控系统设计

至于什么是ganglia就不说了，通过ganglia可以获取一个xml格式个具体的监控数据，很详细，当然如果认为要监控的数据少了，可以自己写个插件玩玩。

初步设计：
1、增加IP管理的表，针对这个管理的功能可以自己定义；
2、增加后台运行执行的脚本：判断IP是否超过一定时间没接收到数据了，然后可以设置是否报警，报警给谁等等；
3、用C或者python写自定义的插件，以满足自己的需求；
4、一些小细节的优化，比如：前端页面的美观、显示更多的link等等；
还有其他可以做到的东西很多，回头再来折腾。

Linux System and Performance Monitoring(Network篇)
Date: 2009.07.21
Author: Darren Hoch
译: Tonnyom[AT]hotmail.com

接前3篇：

Linux System and Performance Monitoring(CPU篇)

Linux System and Performance Monitoring(Memory篇)

Linux System and Performance Monitoring(I/O篇)

8.0 Network 监控介绍

在所有的子系统监控中,网络是最困难的.这主要是由于网络概念很抽象.当监控系统上的网络性能,这有太多因素.这些因素包括了延迟,冲突,拥挤和数据包丢失.

这个章节讨论怎么样检查Ethernet(译注:网卡),IP,TCP的性能.

8.1 Ethernet Configuration Settings(译注:网卡配置的设置)

除非很明确的指定,几乎所有的网卡都是自适应网络速度.当一个网络中有很多不同的网络设备时,会各自采用不同的速率和工作模式.

多数商业网络都运行在100 或 1000BaseTX.使用ethtool 可以确定这个系统是处于那种速率.

以下的例子中,是一个有100BaseTX 网卡的系统,自动协商适应至10BaseTX 的情况.

# 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: 0×00000007 (7)
Link detected: yes

以下示范例子中,如何强制网卡速率调整至100BaseTX:

# ethtool -s eth0 speed 100 duplex full autoneg off

# 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: 0×00000007 (7)
Link detected: yes

8.2 Monitoring Network Throughput(译注:网络吞吐量监控)

接口之间的同步并不意味着仅仅有带宽问题.重要的是,如何管理并优化,这2台主机之间的交换机,网线,或者路由器.测试网络吞吐量最好的方式就是,在这2个系统之间互相发送数据传输并统计下来,比如延迟和速度.

8.2.0 使用iptraf 查看本地吞吐量

iptraf 工具(http://iptraf.seul.org),提供了每个网卡吞吐量的仪表盘.

#iptraf -d eth0

Figure 1: Monitoring for Network Throughput

从输出中可看到,该系统发送传输率(译注:Outgoing rates)为 61 mbps,这对于100 mbps网络来说,有点慢.

8.2.1 使用netperf 查看终端吞吐量

不同于iptraf 被动的在本地监控流量,netperf 工具可以让管理员,执行更加可控的吞吐量监控.对于确定从客户端工作站到一个高负荷的服务器端(比如file 或web server),它们之间有多少吞吐量是非常有帮助的.netperf 工具运行的是client/server 模式.

完成一个基本可控吞吐量测试,首先netperf server 必须运行在服务器端系统上:

server# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

netperf 工具可能需要进行多重采样.多数基本测试就是一次标准的吞吐量测试.以下例子就是,一个LAN(译注:局域网) 环境下,从client 上执行一次30秒的TCP 吞吐量采样:

从输出可看出,该网络的吞吐量大致在89 mbps 左右.server(192.168.1.215) 与client 在同一LAN 中.这对于100 mbps网络来说,性能非常好.

client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.02 89.46

从LAN 切换到具备54G(译注:Wireless-G是未来54Mbps无线网联网标准)无线网络路由器中,并在10 英尺范围内测试时.该吞吐量就急剧的下降.在最大就为54 MBits的可能下,笔记本电脑可实现总吞吐量就为14 MBits.

client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.10 14.09

如果在50英尺范围内呢,则进一步会下降至5 MBits.

# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.64 5.05

如果从LAN 切换到互联网上,则吞吐量跌至1 Mbits下了.

# netperf -H litemail.org -p 1500 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
litemail.org (72.249.104.14 port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 31.58 0.93

最后是一个VPN 连接环境,这是所有网络环境中最槽糕的吞吐量了.

# netperf -H 10.0.1.129 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
10.0.1.129 (10.0.1.129) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 31.99 0.51

另外,netperf 可以帮助测试每秒总计有多少的TCP 请求和响应数.通过建立单一TCP 连接并顺序地发送多个请求/响应(ack 包来回在1个byte 大小).有点类似于RDBMS 程序在执行多个交易或者邮件服务器在同一个连接管道中发送邮件.

以下例子在30 秒的持续时间内,模拟TCP 请求/响应:

client# netperf -t TCP_RR -H 192.168.1.230 -l 30
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 4453.80
16384 87380

在输出中看出,这个网络支持的处理速率为每秒4453 psh/ack(包大小为1 byte).这其实是理想状态下,因为实际情况时,多数requests(译注:请求),特别是responses(译注:响应),都大于1 byte.

现实情况下,netperf 一般requests 默认使用2K大小,responses 默认使用32K大小:

client# netperf -t TCP_RR -H 192.168.1.230 -l 30 — -r 2048,32768
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 2048 32768 30.00 222.37
16384 87380

这个处理速率减少到了每秒222.

8.2.2 使用iperf 评估网络效率

基于都是需要在2端检查连接情况下,iperf 和netperf 很相似.不同的是,iperf 更深入的通过windows size和QOS 设备来检查TCP/UDP 的效率情况.这个工具,是给需要优化TCP/IP stacks以及测试这些stacks 效率的管理员们量身定做的.

iperf 作为一个二进制程序,可运行在server 或者client 任一模式下.默认使用50001 端口.

首先启动server 端(192.168.1.215):

server# iperf -s -D
Running Iperf Server as a daemon
The Iperf daemon process ID : 3655
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————

在以下例子里,一个无线网络环境下,其中client 端重复运行iperf,用于测试网络的吞吐量情况.这个环境假定处于被充分利用状态,很多主机都在下载ISO images文件.

首先client 端连接到server 端(192.168.1.215),并在总计60秒时间内,每5秒进行一次带宽测试的采样.

client# iperf -c 192.168.1.215 -t 60 -i 5
————————————————————
Client connecting to 192.168.1.215, TCP port 5001
TCP window size: 25.6 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 51978 connected with
192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 6.22 MBytes 10.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 5.0-10.0 sec 6.05 MBytes 10.1 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 10.0-15.0 sec 5.55 MBytes 9.32 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 15.0-20.0 sec 5.19 MBytes 8.70 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 20.0-25.0 sec 4.95 MBytes 8.30 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 25.0-30.0 sec 5.21 MBytes 8.74 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 30.0-35.0 sec 2.55 MBytes 4.29 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 35.0-40.0 sec 5.87 MBytes 9.84 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 40.0-45.0 sec 5.69 MBytes 9.54 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 45.0-50.0 sec 5.64 MBytes 9.46 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 50.0-55.0 sec 4.55 MBytes 7.64 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 55.0-60.0 sec 4.47 MBytes 7.50 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 61.9 MBytes 8.66 Mbits/sec

这台主机的其他网络传输,也会影响到这部分的带宽采样.所以可以看到总计60秒时间内,都在4 - 10 MBits 上下起伏.

除了TCP 测试之外,iperf 的UDP 测试主要是评估包丢失和抖动.

接下来的iperf 测试,是在同样的54Mbit G标准无线网络中.在早期的示范例子中,目前的吞吐量只有9 Mbits.

# iperf -c 192.168.1.215 -b 10M
WARNING: option -b implies udp testing
————————————————————
Client connecting to 192.168.1.215, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 107 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 33589 connected with 192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.8 MBytes 9.90 Mbits/sec
[ 3] Sent 8420 datagrams
[ 3] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 6.50 MBytes 5.45 Mbits/sec 0.480 ms 3784/ 8419 (45%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

从输出中可看出,在尝试传输10M 的数据时,实际上只产生了5.45M.却有45% 的包丢失.

8.3 Individual Connections with tcptrace

tcptrace 工具提供了对于某一具体连接里,详细的TCP 相关信息.该工具使用libcap 来分析某一具体TCP sessions.该工具汇报的信息,有时很难在某一TCP stream被发现.这些信息

包括了有:

1,TCP Retransmissions(译注:IP 转播) - 所有数据大小被发送所需的包总额
2,TCP Windows Sizes - 连接速度慢与小的windows sizes 有关
3,Total throughput of the connection - 连接的吞吐量
4,Connection duration - 连接的持续时间

8.3.1 案例学习 - 使用tcptrace

tcptrace 工具可能已经在部分Linux 发布版中有安装包了,该文作者通过网站,下载的是源码安装包:http://dag.wieers.com/rpm/packages /tcptrace.tcptrace 需要libcap 基于文件输入方式使用.在tcptrace 没有选项的情况下,默认每个唯一的连接过程都将被捕获.

以下例子是,使用libcap 基于输入文件为bigstuff:

# tcptrace bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:01.634065, 89413 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
1: 192.168.1.60:pcanywherestat - 192.168.1.102:2571 (a2b) 404> 450< 2: 192.168.1.60:3356 - ftp.strongmail.net:21 (c2d) 35> 21< 3: 192.168.1.60:3825 - ftp.strongmail.net:65023 (e2f) 5> 4< (complete) 4: 192.168.1.102:1339 - 205.188.8.194:5190 (g2h) 6> 6< 5: 192.168.1.102:1490 - cs127.msg.mud.yahoo.com:5050 (i2j) 5> 5< 6: py-in-f111.google.com:993 - 192.168.1.102:3785 (k2l) 13> 14<

上面的输出中,每个连接都有对应的源主机和目的主机.tcptrace 使用-l 和-o 选项可查看某一连接更详细的数据.

以下的结果,就是在bigstuff 文件中,#16 连接的相关统计数据:

# tcptrace -l -o1 bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.529361, 276008 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
32 TCP connections traced:
TCP connection 1:
host a: 192.168.1.60:pcanywherestat
host b: 192.168.1.102:2571
complete conn: no (SYNs: 0) (FINs: 0)
first packet: Sun Jul 20 15:58:05.472983 2008
last packet: Sun Jul 20 16:00:04.564716 2008
elapsed time: 0:01:59.091733
total packets: 854
filename: bigstuff
a->b: b->a:
total packets: 404 total packets: 450
ack pkts sent: 404 ack pkts sent: 450
pure acks sent: 13 pure acks sent: 320
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 52608 unique bytes sent: 10624
actual data pkts: 391 actual data pkts: 130
actual data bytes: 52608 actual data bytes: 10624
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 391 pushed data pkts: 130
SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 0 bytes mss requested: 0 bytes
max segm size: 560 bytes max segm size: 176 bytes
min segm size: 48 bytes min segm size: 80 bytes
avg segm size: 134 bytes avg segm size: 81 bytes
max win adv: 19584 bytes max win adv: 65535 bytes
min win adv: 19584 bytes min win adv: 64287 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 19584 bytes avg win adv: 64949 bytes
initial window: 160 bytes initial window: 0 bytes
initial window: 2 pkts initial window: 0 pkts
ttl stream length: NA ttl stream length: NA
missed data: NA missed data: NA
truncated data: 36186 bytes truncated data: 5164 bytes
truncated packets: 391 pkts truncated packets: 130 pkts
data xmit time: 119.092 secs data xmit time: 116.954 secs
idletime max: 441267.1 ms idletime max: 441506.3 ms
throughput: 442 Bps throughput: 89 Bps

8.3.2 案例学习 - 计算转播率

几乎不可能确定说哪个连接会有严重不足的转播问题,只是需要分析,使用tcptrace 工具可以通过过滤机制和布尔表达式来找出出问题的连接.一个很繁忙的网络中,会有很多的连接,几乎所有的连接都会有转播.找出其中最多的一个,这就是问题的关键.

下面的例子里,tcptrace 将找出那些转播大于100 segments(译注:分段数)的连接:

# tcptrace -f’rexmit_segs>100′ bigstuff
Output filter: ((c_rexmit_segs>100)OR(s_rexmit_segs>100))
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.687788, 212431 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
16: ftp.strongmail.net:65014 - 192.168.1.60:2158 (ae2af) 18695> 9817< 在这个输出中,是#16 这个连接里,超过了100 转播.现在,使用以下命令查看关于这个连接的其他信息: # tcptrace -l -o16 bigstuff arg remaining, starting with ‘bigstuff’ Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004 146108 packets seen, 145992 TCP packets traced elapsed wallclock time: 0:00:01.355964, 107752 pkts/sec analyzed trace file elapsed time: 0:09:20.358860 TCP connection info: 32 TCP connections traced: ================================ TCP connection 16: host ae: ftp.strongmail.net:65014 host af: 192.168.1.60:2158 complete conn: no (SYNs: 0) (FINs: 1) first packet: Sun Jul 20 16:04:33.257606 2008 last packet: Sun Jul 20 16:07:22.317987 2008 elapsed time: 0:02:49.060381 total packets: 28512 filename: bigstuff ae->af: af->ae:

unique bytes sent: 25534744 unique bytes sent: 0
actual data pkts: 18695 actual data pkts: 0
actual data bytes: 25556632 actual data bytes: 0
rexmt data pkts: 1605 rexmt data pkts: 0
rexmt data bytes: 2188780 rexmt data bytes: 0

计算转播率:
rexmt/actual * 100 = Retransmission rate

1605/18695* 100 = 8.5%

这个慢连接的原因,就是因为它有8.5% 的转播率.

8.3.3 案例学习 - 计算转播时间

tcptrace 工具有一系列的模块展示不同的数据,按照属性,其中就有protocol(译注:协议),port(译注:端口),time等等.Slice module使得你可观察在一段时间内的TCP 性能.你可以在一系列的转发过程中,查看其他性能数据,以确定找出瓶颈.

以下例子示范了,tcptrace 是怎样使用slice 模式的:

# tcptrace –xslice bigfile

以上命令会创建一个slice.dat 文件在现在的工作目录中.这个文件内容,包含是每15秒间隔内转播的相关信息:

# ls -l slice.dat
-rw-r–r– 1 root root 3430 Jul 10 22:50 slice.dat
# more slice.dat
date segs bytes rexsegs rexbytes new active
————— ——– ——– ——– ——– ——– ——–
22:19:41.913288 46 5672 0 0 1 1
22:19:56.913288 131 25688 0 0 0 1
22:20:11.913288 0 0 0 0 0 0
22:20:26.913288 5975 4871128 0 0 0 1
22:20:41.913288 31049 25307256 0 0 0 1
22:20:56.913288 23077 19123956 40 59452 0 1
22:21:11.913288 26357 21624373 5 7500 0 1
22:21:26.913288 20975 17248491 3 4500 12 13
22:21:41.913288 24234 19849503 10 15000 3 5
22:21:56.913288 27090 22269230 36 53999 0 2
22:22:11.913288 22295 18315923 9 12856 0 2
22:22:26.913288 8858 7304603 3 4500 0 1

8.4 结论

监控网络性能由以下几个部分组成:

1,检查并确定所有网卡都工作在正确的速率.
2,检查每块网卡的吞吐量,并确认其处于服务时的网络速度.
3,监控网络流量的类型,并确定适当的流量优先级策略.

上一篇：

Linux System and Performance Monitoring(I/O篇)

下一篇：

Linux System and Performance Monitoring(总结篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/13/linux-system-and-performance-monitoringnetwork%E7%AF%87/

Linux System and Performance Monitoring(CPU篇)
Date:         2009.07.21
Author:    Darren Hoch
译:            Tonnyom[AT]hotmail.com 2009.08.10

前言: 网上其实有很多关于这方面的文章,那为什么还会有此篇呢,有这么几个原因,是我翻译的动力,第一,概念和内容虽然老套,但都讲得很透彻,而且还很全面.第二,理论结合实际,其中案例分析都不错.第三,不花哨,采用的工具及命令都是最基本的,有助于实际操作.但本人才疏学浅,译文大多数都是立足于自己对原文的理解,大家也可以自己去OSCAN上找原文,如果有什么较大出入,还望留言回复,甚是感激!

1.0 性能监控介绍

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

CPU
Memory
IO
Network

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

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

1.1 确定应用类型

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

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 范畴的应用类型.

1.2 确定基准线统计

系统利用率情况,一般随管理员经验以及系统本身用途来决定.唯一要清楚的就是,系统优化希望达成什么效果,以及哪些方面是需要优化,还有参考值是什么?因此就建立一个基准线,这个统计数据必须是系统可用性能状态值,用来比较不可用性能状态值.

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

# 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

从上面第一个结果可看到,最后一列(id) 表示的是空闲时间,我们可以看到,在基准线统计时,CPU 的空闲时间在79% - 100%.在第二个结果可看到,系统处于100%的占用率以及没有空闲时间.从这个比较中,我们就可以确定是否是CPU 使用率应该被优化.

2.0 安装监控工具

多数 *nix系统都有一堆标准的监控命令.这些命令从一开始就是*nix 的一部分.Linux 则通过基本安装包以及额外包提供了其他监控工具,这些安装包多数都存在各个Linux 发布版本中.尽管还有其他更多的开源以及第三方监控软件,但本文档只讨论基于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
netperf      Network bandwidth tool              no      In some distributions
ethtool      reports on Ethernet interface configuration      yes      yes
iperf          Network bandwidth tool              no      yes
tcptrace      Packet analysis tool                  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秒间隔的示例:

# 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

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 利用率

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

# 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

根据观察值,我们可以得到以下结论:

1,有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.

2,进一步显示某单个应用,user time(us) 经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.

3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.

4.3 案例学习:超负荷调度

在这个例子中,内核调度中的上下文切换处于饱和

# 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

根据观察值,我们可以得到以下结论:

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 可以给出基于单个处理器的统计值.

# 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.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 范畴的应用处理将受到影响

下一篇：

Linux System and Performance Monitoring(Memory篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/10/linux-system-and-performance-monitoring-cpu/

最近在构思监控系统的设计，大的分类包括：

1. 应用监控（对具体业务的监控，监控可服务情况）
2. 物理监控（主要是底层的资源监控，监控资源件的利用率）

估计近期就会编码了…

S1：3H1L

何谓3H1L？

• 高可用
• 高性能
• 高安全
• 低成本

为什么要实现3H1L？

将3H1L作为一个系统运营的终极目标，对公司整体运营是非常有好处的，这也将为公司利益最大化提供一个非常好的平台和基础，特别是互联网企业。

那么如何来实现？有哪些途径？

知道了3H1L的定义后，下面就要知道我们如何来实现，下面的三点，做个参考记录下：

1. 合理的架构
2. 较完善的流程体系
3. 较完善的监控体系

在介绍架构前，我们必须要知道组成Web站点的元素，但是在之前，我想还是先来看看性能参数，以便为Web站点元素优化的时候提供参考。

查看下一章：《性能参数》