网络的监测是所有 Linux 子系统里面最复杂的,有太多的因素在里面,比如:延迟、阻塞、冲突、丢包等,更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题,增加了监测和判断的复杂度。

网络的监测是所有 Linux 子系统里面最复杂的,有太多的因素在里面,比如:延迟、阻塞、冲突、丢包等,更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题,增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡,意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。我们可以通过 ethtool 工具来查看网卡的配置和工作模式:

上面给出的例子说明网卡有 10baseT,100baseT 和 1000baseT 三种选择,目前正自适应为 100baseT(Speed: 100Mb/s)。可以通过 ethtool 工具强制网卡工作在 1000baseT 下:

# /sbin/ethtool -s eth0 speed 1000 duplex full autoneg off

iptraf

两台主机之间有网线(或无线)、路由器、交换机等设备,测试两台主机之间的网络性能的一个办法就是在这两个系统之间互发数据并统计结果,看看吞吐量、延迟、速率如何。iptraf 就是一个很好的查看本机网络吞吐量的好工具,支持文字图形界面,很直观。下面图片显示在 100 mbps 速率的网络下这个 Linux 系统的发送传输率有点慢,Outgoing rates 只有 66 mbps.

# iptraf -d eth0

netperf

netperf 运行在 client/server 模式下,比 iptraf 能更多样化的测试终端的吞吐量。先在服务器端启动 netserver:

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

然后在客户端测试服务器,执行一次持续10秒的 TCP 测试:

# netperf -H 172.16.38.36 -l 10
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) 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 10.32 93.68

从以上输出可以看出,网络吞吐量在 94mbps 左右,对于 100mbps 的网络来说这个性能算的上很不错。上面的测试是在服务器和客户端位于同一个局域网,并且局域网是有线网的情况,你也可以试试不同结构、不同速率的网络,比如:网络之间中间多几个路由器、客户端在 wi-fi、VPN 等情况。

netperf 还可以通过建立一个 TCP 连接并顺序地发送数据包来测试每秒有多少 TCP 请求和响应。下面的输出显示在 TCP requests 使用 2K 大小,responses 使用 32K 的情况下处理速率为每秒243:

# netperf -t TCP_RR -H 172.16.38.36 -l 10 -- -r 2048,32768
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) 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 10.00 243.03
16384 87380

iperf

iperf 和 netperf 运行方式类似,也是 server/client 模式,先在服务器端启动 iperf:

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

然后在客户端对服务器进行测试,客户端先连接到服务器端(172.16.38.36),并在30秒内每隔5秒对服务器和客户端之间的网络进行一次带宽测试和采样:

# iperf -c 172.16.38.36 -t 30 -i 5
------------------------------------------------------------
Client connecting to 172.16.38.36, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.39.100 port 49515 connected with 172.16.38.36 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 58.8 MBytes 98.6 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 5.0-10.0 sec 55.0 MBytes 92.3 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 10.0-15.0 sec 55.1 MBytes 92.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 15.0-20.0 sec 55.9 MBytes 93.8 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 20.0-25.0 sec 55.4 MBytes 92.9 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 25.0-30.0 sec 55.3 MBytes 92.8 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 335 MBytes 93.7 Mbits/sec

tcpdump 和 tcptrace

tcmdump 和 tcptrace 提供了一种更细致的分析方法,先用 tcpdump 按要求捕获数据包把结果输出到某一文件,然后再用 tcptrace 分析其文件格式。这个工具组合可以提供一些难以用其他工具发现的信息:

# /usr/sbin/tcpdump -w network.dmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
511942 packets captured
511942 packets received by filter
0 packets dropped by kernel # tcptrace network.dmp
1 arg remaining, starting with 'network.dmp'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 511677 packets seen, 511487 TCP packets traced
elapsed wallclock time: 0:00:00.510291, 1002714 pkts/sec analyzed
trace file elapsed time: 0:02:35.836372
TCP connection info:
1: zaber:54581 - boulder:111 (a2b) 6> 5< (complete)
2: zaber:833 - boulder:32774 (c2d) 6> 5< (complete)
3: zaber:pcanywherestat - 172.16.39.5:53086 (e2f) 2> 3<
4: zaber:716 - boulder:2049 (g2h) 347> 257<
5: 172.16.39.100:58029 - zaber:12865 (i2j) 7> 5< (complete)
6: 172.16.39.100:47592 - zaber:36814 (k2l) 255380> 255378< (reset)
7: breakpoint:45510 - zaber:7012 (m2n) 9> 5< (complete)
8: zaber:35813 - boulder:111 (o2p) 6> 5< (complete)
9: zaber:837 - boulder:32774 (q2r) 6> 5< (complete)
10: breakpoint:45511 - zaber:7012 (s2t) 9> 5< (complete)
11: zaber:59362 - boulder:111 (u2v) 6> 5< (complete)
12: zaber:841 - boulder:32774 (w2x) 6> 5< (complete)
13: breakpoint:45512 - zaber:7012 (y2z) 9> 5< (complete)

tcptrace 功能很强大,还可以通过过滤和布尔表达式来找出有问题的连接,比如,找出转播大于100 segments 的连接:

# tcptrace -f'rexmit_segs>100' network.dmp

如果发现连接 #10 有问题,可以查看关于这个连接的其他信息:

# tcptrace -o10 network.dmp

下面的命令使用 tcptrace 的 slice 模式,程序自动在当前目录创建了一个 slice.dat 文件,这个文件包含了每隔15秒的转播信息:

# tcptrace -xslice network.dmp

# cat slice.dat
date segs bytes rexsegs rexbytes new active
--------------- -------- -------- -------- -------- -------- --------
16:58:50.244708 85055 4513418 0 0 6 6
16:59:05.244708 110921 5882896 0 0 0 2
16:59:20.244708 126107 6697827 0 0 1 3
16:59:35.244708 151719 8043597 0 0 0 2
16:59:50.244708 37296 1980557 0 0 0 3
17:00:05.244708 67 8828 0 0 2 3
17:00:20.244708 149 22053 0 0 1 2
17:00:35.244708 30 4080 0 0 0 1
17:00:50.244708 39 5688 0 0 0 1
17:01:05.244708 67 8828 0 0 2 3
17:01:11.081080 37 4121 0 0 1 3

Linux性能监测:网络篇的更多相关文章

  1. Linux性能监测:CPU篇(转)

    http://os.51cto.com/art/201012/239880.htm CPU 的占用主要取决于什么样的资源正在 CPU 上面运行,比如拷贝一个文件通常占用较少 CPU,因为大部分工作是由 ...

  2. Linux性能监测:磁盘IO篇

    磁盘通常是计算机最慢的子系统,也是最容易出现性能瓶颈的地方,因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作,比如转轴.寻轨等.访问硬盘和访问内存之间的速度差别是以数量级来计算的,就 ...

  3. Linux性能监测:内存篇

    在操作系统里,虚拟内存被分成页,在 x86 系统上每个页大小是 4KB.Linux 内核读写虚拟内存是以 “页” 为单位操作的,把内存转移到硬盘交换空间(SWAP)和从交换空间读取到内存的时候都是按页 ...

  4. Linux性能监测:CPU篇

    CPU 也是一种硬件资源,和任何其他硬件设备一样也需要驱动和管理程序才能使用,我们可以把内核的进程调度看作是 CPU 的管理程序,用来管理和分配 CPU 资源,合理安排进程抢占 CPU,并决定哪个进程 ...

  5. Linux性能监测

    1.Linux性能监测:监测目的与工具介绍 看了某某教程.读了某某手册,按照要求改改某些设置.系统设定.内核参数就认为做到系统优化的想法很傻很天真:)系统优化是一项复杂.繁琐.长期的工作,优化前需要监 ...

  6. pyDash:一个基于 web 的 Linux 性能监测工具

    pyDash 是一个轻量且基于 web 的 Linux 性能监测工具,它是用 Python 和 Django 加上 Chart.js 来写的.经测试,在下面这些主流 Linux 发行版上可运行:Cen ...

  7. Linux性能监测:监测目的与工具

    Linux性能监测:监测目的与工具介绍 系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不是说现在优化了,测试了 ...

  8. Linux 性能监测:IO

    磁盘通常是计算机最慢的子系统,也是最容易出现性能瓶颈的地方,因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作,比如转轴.寻轨等.访问硬盘和访问内存之间的速度差别是以数量级来计算的,就 ...

  9. Linux 性能监测:Memory

    这里的讲到的 "内存" 包括物理内存和虚拟内存,虚拟内存(Virtual Memory)把计算机的内存空间扩展到硬盘,物理内存(RAM)和硬盘的一部分空间(SWAP)组合在一起作为 ...

  10. Linux 性能监测:CPU

    CPU 的占用主要取决于什么样的资源正在 CPU 上面运行,比如拷贝一个文件通常占用较少 CPU,因为大部分工作是由 DMA(Direct Memory Access)完成,只是在完成拷贝以后给一个中 ...

随机推荐

  1. 命令行连接db2数据库

    在cmd界面执行db2cmd命令 然后在db2cmd界面执行db2命令 然后执行 CONNECT TO UIBS USER DB2INST1 USING 123456命令

  2. 011-对象——interface接口说明与使用方式实例

    <?php /** interface接口说明与使用方式实例 * * 接口里面的方法全是抽象方法,没有实体的方法.这样的类我们就叫做接口.定义的时候用Interface定义.实现接口时用impl ...

  3. Django的 CBV和FBV

    FBV CBV 回顾多重继承和Mixin 回到顶部 FBV FBV(function base views) 就是在视图里使用函数处理请求. 在之前django的学习中,我们一直使用的是这种方式,所以 ...

  4. LeetCode OJ:Valid Anagram(有效字谜问题)

    Given two strings s and t, write a function to determine if t is an anagram of s. For example,s = &q ...

  5. react: next-redux-saga

    instead of using the Provider component, you can use the withRedux higher order component to inject ...

  6. js 复制粘贴功能记录

    最近工作中需要在前端页面中使用代码完成剪贴板的读写,网上搜索了下相应的资料,记录下... 这个功能有两个办法一个是js方式,一个是使用flash 一.JS方法 1.复制 首先复制的过程分为两步曲,无论 ...

  7. Leetcode 986. Interval List Intersections

    暴搜.. class Solution(object): def intervalIntersection(self, A: List[Interval], B: List[Interval]) -& ...

  8. ng $interval(周期性定时器) $timeout(延迟定时器)

    <!DOCTYPE html> <html ng-app="myApp"> <head lang="en"> <met ...

  9. js 函数里的 this

    1,当作为纯粹的函数调用时, this指向调用出的环境的上下文,看下面的例子 var x = 1; function test(){ var x = 0; alert( alert(x); } tes ...

  10. sublime上配置markdown

    等等等等 简书一个不错的教程:Sublime Text3的Markdown配置 补充说明:第一步可以直接找 Tools-->install package control. ^.^ ...