Linux System and Performance Monitoring(Network篇)

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 8) 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

最后是一个××× 链接环境,这是全部网络环境中最槽糕的吞吐量了.

# 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 p_w_picpaths文件.

首先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,监控网络流量的类型,并肯定适当的流量优先级策略.