AIX网络性能分析报告.doc

WORD
出现性能问题的时候，您的系统可能一点过失也没有，而真正的故障原因却是外面的建筑物。如果要知道是否是网络影响总体的性能，一个简单的方法就是比较涉与网络的操作和那些和网络无关的操作。如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。一些潜在的网络瓶颈可能由以下因素造成：

* 客户端网络接口s
* 网络带宽
* 网络拓扑结构
* 服务器端网络接口
* 服务器端 CPU 负载
* 服务器存储器使用状况
* 服务器带宽
* 配置效率低下

一些工具能够进行网络资料统计，给出各种各样的信息，但只有其中的一部分是和性能调谐相关的。

为了改善性能，您可以使用 no （网络选项）命令和 nfso 命令来对 NFS 选项进行调谐。您还可以使用 chdev 和 ifconfig 命令来改变系统和网络的参数值。
ping 命令

在下面这些情况下 ping 命令是有帮助的：

* 确定网络的状态和各种外部主机。
* 跟踪并隔离硬件和软件故障。
* 对网络的检测、测定和管理。

下面列出的是一些和性能调谐相关联的 ping 命令参数项：

-c
指定了信息包数。如果您有 IP 跟踪记录，这个参数项是有用的。您可以捕捉到 ping 信息包的最小值。
-s
指定信息包的长度。您可以使用这个参数项来检查分段和重新组合。
-f
以 10 ms 的间歇发送信息包或是在每次回应之后立即发送。只有根用户才可以使用这个参数项。

如果您需要加载您的网络或系统，使用 -f 参数项就很方便。比如，如果您猜测您的故障是过量负载造成的，可以试着有意加载您的工作区来证实您的怀疑。打开一些 aixterm 窗口，并在每个窗口中运行 ping -f 命令。您的以太网使用状况很快就会达到接近 100%。下面是一个例子：

# date ; ping -c 1000 -f wave ; date
Fri Jul 23 11:52:39 CDT 1999
PING wave.austin.ibm.: (9.53.153.120): 56 data bytes
.
----wave.austin.ibm. PING Statistics----
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max = 1/1/23 ms
Fri Jul 23 11:52:42 CDT 1999

注:
这个命令在网络上运行可能很困难，要小心使用。连续地执行 ping 命令只能由根用户来操作。

在这个例子中，1000 个信息包发送了 3 秒。要知道这个命令使用了 IP 和网络控制信息协议（ICMP），因而没有涉与到任何传输协议（UDP/TCP）和应用程序。测到的数据，比如往返的时间，不会影响到总体的性能特征。

如果您试图发送大量的信息包到您的目的地址，就要考虑如下几点：

* 发送信息包对您的系统来说，增加了负载。
* 使用 netstat -i 命令可以在试验过程中监测您的网络接口的状态。通过查看 Oerrs 的输出您可以发现系统在发送中在删除信息包。
* 您也应该监控其他资源，比如 mbuf 和发送 / 接收队列。很难在目标系统上增加一个大的负载。或许在其他系统过载之前您的系统就过载了。
* 考虑结果的相关性。如果您想监控或测试的仅是一个目标系统，就在其他的一些系统上做同样的试验来进行比较，因为或许您的网络或是路由器出现了故障。

ftp 命令

您可以使用 ftp 命令来发送一个非常大的文件，使用 /dev/zero 作为输入，/dev/null 作为输出。这样您就可以传输一个大文件，而不用考虑磁盘（可能是瓶颈问题），也不需要在存中高速缓存整个文件。

使用下面的 ftp 子命令（改变 count 的值可以增加或是减少块的数量，块的数量可以通过 dd 命令读出）：

> bin
> put "|dd if=/dev/zero bs=32k count=10000" /dev/null

记住，如果您改变了 TCP 的发送或接收空间参数，对于 ftp 命令，您必须刷新 inetd 守护程序，使用 refresh -s inetd 命令就可以刷新。

要确保 tcp_senspace 和 tcp_recvspace 的值至少为 65535 （对于 Gigabit 以太网 "jumbo frames"和带有 MTU 9180 的 ATM 来说），如果要获得更好的性能就需要更大的值，这是因为 MTU 的值也增加了。

下面举的是一个设置参数的例子：

# no -o tcp_sendspace=65535
# no -o tcp_recvspace=65535
# refresh -s inetd
# refresh -s inetd
0513-095 刷新子系统的请求成功完成。

下面列出的是 ftp 子命令：

ftp> bin
200 Type set to I.
ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
10000+0 records in
10000+0 records out
226 Transfer complete.
327680000 bytes sent in 8.932 seconds (3.583e+04 Kbytes/s)
local: |dd if=/dev/zero bs=32k count=10000 remote: /dev/null
ftp> quit
221 Goodbye.

网络统计命令

netstat 命令可以用来显示网络的状态。按惯例来看，它是用来做故障识别而不是作为性能评定用的。然而，netstat 命令可以用来确定网络上的流量，从而可以确定性能故障是否是由于网络阻塞所引起。

netstat 命令显示的是关于在配置的网络接口上的流量，如下面所示：

* 和套接字有关的任何一个协议控制块的地址与所有套接字的状态
* 收到、发送出去和在通信子系统中丢失的信息包数量
* 每个接口的累计统计信息
* 路由和它们的状态

使用 netstat 命令

netstat 命令显示的是有效连接的各种网络相关的数据结构容。本章中只讨论和网络性能决定性相关的参数项和输出域。对于其他所有的参数项和栏目，请参阅《AIX 5L V5.2 命令参考大全》。
netstat -i

显示的是所有配置接口的状态。

下面的例子显示的是一个带有集成以太网和 Token-Ring 适配器的工作站的统计信息：

# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 <Link> 144834 0 144946 0 0
lo0 16896 127 localhost 144834 0 144946 0 0
tr0 1492 <Link>10.0.5a.4f.3f.61 658339 0 247355 0 0
tr0 1492 9.3.1 ah6000d 658339 0 247355 0 0
en0 1500 <Link>8.0.5a.d.a2.d5 0 0 112 0 0
en0 1500 1.2.3 1.2.3.4 0 0 112 0 0

count 的值从系统启动开始进行汇总。

Name
接口名称。
Mtu
最大传输单元。使用接口时可以传输的最大信息包大小，以字节为单位。
Ipkts
接收到信息包的总数量。
Ierrs
输入错误的总次数。比如，畸形的信息包、校验和错误或是设备驱动程序中的缓冲空间不足。
Opkts
发送信息包的总数量。
Oerrs
输出错误的总数。比如，主机连接的错误或是适配器输出队列超限。
Coll
检测到的信息包冲突的次数。

注:
netstat -i 命令并不和以太网接口下的冲突次数相匹配（请参阅以太网统计资料的 netstat 命令）。

下面时一些调谐的准则：

* 如果输入信息包中的错误次数比输出信息包总数的 1% 还要大（从 netstat -i）命令可以看出，即是说，

Ierrs > 0.01 x Ipkts

那么就运行 netstat -m 命令来检查存储器的不足。
* 如果输出信息包中的错误次数比输出信息包总数的 1% 还要大（从 netstat -i）命令可以看出，即是说，

Oerrs > 0.01 x Opkts

那么就为这个接口增加发送队列的大小（xmt_que_size）。 xmt_que_size 的大小可以通过下面的命令来检查：

# lsattr -El adapter

* 如果冲突的比率比 10% 要大，即是，

Coll / Opkts > 0.1

那么网络的使用率就比较高，这时或许就有必要重新组合或是分区。使用 netstat -v 或者 entstat 命令可以确定冲突的比率。

netstat -i -Z

netstat 命令对所有 netstat -i 命令的计数器进行清零。
netstat -I interface interval

显示指定接口的统计信息。对于一个指定的接口，它提供的信息和 netstat -i 命令类似，并按给定的时间间隔通报。举例来说：

# netstat -I en0 1
input (en0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
0 0 27 0 0 799655 0 390669 0 0
0 0 0 0 0 2 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 78 0 254 0 0
0 0 0 0 0 200 0 62 0 0
0 0 1 0 0 0 0 2 0 0

上面的例子显示的是 netstat -I 命令的输出（对于 ent0 接口来说）。依次生成了两个报告，一个是对指定接口，一个是对所有可用的接口（Total）。这些域和 netstat -i 例子中的很相似，input packets = Ipkts， input errs = Ierrs，等等。
netstat -m

显示 mbuf 存储器管理程序所记录的统计信息。在 netstat -m 命令的输出中最有用的统计信息就是显示被拒绝的 mbuf 请求的计数器和故障一列中的非零值。如果没有显示被拒绝的 mbuf 请求，那么可以肯定 SMP 系统在运行 4.3.2 版本或是更晚版本的操作系统，为了性能方面的原因，缺省设定为关闭全局的统计信息。要启用全局的统计信息，需要把 no 参数 extended_netstats 设定为 1。需要更改 /etc/ 文件然后重启系统，就可以实现设定。

下面的例子显示的是 netstat -m 输出的第一部分，这是 extended_netstats 设定为 1 之后的情况：

# netstat -m
29 mbufs in use:
16 mbuf cluster pages in use
71 Kbytes allocated to mbufs
0 requests for mbufs denied
0 calls to protocol drain routines

核分配统计信息：

******* CPU 0 *******
By size inuse calls failed delayed free hiwat freed
32 419 544702 0 0 221 800 0
64 173 22424 0 0 19 400 0
128 121 37130 0 0 135 200 4
256 1201 118326233 0 0 239 480 138
512 330 671524 0 0 14 50 54
1024 74 929806 0 0 82 125 2
2048 384 1820884 0 0 8 125 5605
4096 516 1158445 0 0 46 150 21
8192 9 5634 0 0 1 12 27
16384 1 2953 0 0 24 30 41
32768 1 1 0 0 0 1023 0

By type inuse calls failed delayed memuse memmax mapb

Streams mblk statistic failures:
0 high priority mblk failures
0 medium priority mblk failures
0 low priority mblk failures

如果全局的统计信息没有处于打开状态，而您想确定被拒绝的 mbuf 请求的总数就可以每个 CPU 下面的 failed 列中的值相叠加。如果 netstat -m 命令表明，向 mbuf 或群集器的请求失败或是被拒绝，这时您或许想增加 thewall 的值，这可以通过 no -othewall= NewValue 命令来实现。要了解细节容，请参阅『mbuf 管理工具』，那里提到了有关 thewall 和 maxmbuf 的使用。

AIX 4.3.3之后，就增加了 delayed 这个列。如果对 mbuf 的请求指定了 M_WAIT 标记，那么如果没有可用的 mbuf 时，线程就会进入睡眠状态，直到有 mbuf 被释放，能够为这个线程所用。这种情况下失效的计数器不会执行增一操作，但 delayed 列会执行增一操作。在 AIX 4.3.3 之前，失效的计数器也不能够进行增一，但那时没有 delayed 这一列。

而且，如果当前分配的网络存储器的大小是 thewall 的 85% 的围，您或许想要增加 thewall 的值。如果 thewall 的值增加，就可以使用 vmstat 命令来监控存储器使用的总量，从而可以确定这个增加对总体的存储器性能是否具有负面影响。

如果接收到一个请求时没有可用的缓冲区，那么这个请求很可能会被删除（如果要查看适配器是否真的删除了包，请参阅『适配器统计信息』）。记住一点，如果 mbuf 的请求方指定，在没有 mbuf 可以立即使用的情况下，它可以等待 mbuf 空闲。这样就会使得请求方进入睡眠状态，但不会作为被拒绝的请求进行计数。

如果失效请求的数量持续增加，可能是因为系统出现了 mbuf 泄漏。为了有助于跟踪故障，可以把 no 命令参数 net_malloc_police 设置为 1，在使用 trace 命令时可以使用标识为 254 的跟踪 hook。

分配一个 mbuf 或是群集器并锁定后，它可以被应用程序所释放。并不是解除这个缓冲区的锁定，把它归还给系统，而是把它置放在一个基于缓冲区大小的自由列表中。下一次再收到请求缓冲区时，就会把它从自由列表中去除，这样就避免了锁定的动作开销。下一次再收到请求缓冲区时，就会把它从自由列表中去除，这样就避免了锁定的动作开销。当自由列表的缓冲区总量达到了高限值之后，大小低于 4096 的缓冲区就会进行合并，组成页面大小的单元，这样就可以解除它们的锁定并归还给系统。缓冲区归还给系统时，freed 列就会进行增一操作。如果 freed 的值持续增大，那么上限值就太低。在 AIX 4.3.2 和后来的系统中，高限值可以根据系统中的 RAM 数量进行比例缩放。
netstat -v

netstat -v 命令显示的是正在运行的每一个基于通用数据接口设备驱动程序的统计信息。至于特定于接口的报告，可以使用 tokstat、entstat、fddistat 或者是 atmstat 命令。

每个接口都有它自身的特定信息和一些通用信息。下面的例子显示的是 netstat -v 命令的 Token-Ring 和以太网部分，其他的接口部分也是类似的。对于不同的适配器而言，统计量会有所不同。最重要的输出字段采用高亮显示。

# netstat -v
-------------------------------------------------------------
ETHERNET STATISTICS (ent0) :
Device Type: IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
Hardware Address: 00:60:94:e9:29:18
Elapsed Time: 9 days 19 hours 5 minutes 51 seconds

Transmit Statistics: Receive Statistics:
-------------------- -------------------
Packets: 0 Packets: 0
Bytes: 0 Bytes: 0
Interrupts: 0 Interrupts: 0
Transmit Errors: 0 Receive Errors: 0
Packets Dropped: 0 Packets Dropped: 0
Bad Packets: 0
Max Packets on S/W Transmit Queue: 0
S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 0

Broadcast Packets: 0 Broadcast Packets: 0
Multicast Packets: 0 Multicast Packets: 0
No Carrier Sense: 0 CRC Errors: 0
DMA Underrun: 0 DMA Overrun: 0
Lost CTS Errors: 0 Alignment Errors: 0
Max Collision Errors: 0 No Resource Errors: 0
Late Collision Errors: 0 Receive Collision Errors: 0
Deferred: 0 Packet Too Short Errors: 0
SQE Test: 0 Packet Too Long Errors: 0
Timeout Errors: 0 Packets Discarded by Adapter: 0
Single Collision Count: 0 Receiver Start Count: 0
Multiple Collision Count: 0
Current HW Transmit Queue Length: 0

General Statistics:
-------------------
No mbuf Errors: 0
Adapter Reset Count: 0
Driver Flags: Up Broadcast Running
Simplex 64BitSupport PrivateSegment

IBM 10/100 Mbps Ethernet PCI Adapter Specific Statistics:
------------------------------------------------
Chip Version: 25
RJ45 Port Link Status : down
Media Speed Selected: 10 Mbps Half Duplex
Media Speed Running: Unknown
Receive Pool Buffer Size: 384
Free Receive Pool Buffers: 128
No Receive Pool Buffer Errors: 0
Inter Packet Gap: 96
Adapter Restarts due to IOCTL commands: 0
Packets with Transmit collisions:
1 collisions: 0 6 collisions: 0 11 collisions: 0
2 collisions: 0 7 collisions: 0 12 collisions: 0
3 collisions: 0 8 collisions: 0 13 collisions: 0
4 collisions: 0 9 collisions: 0 14 collisions: 0
5 collisions: 0 10 collisions: 0 15 collisions: 0
Excessive deferral errors: 0x0
-------------------------------------------------------------
TOKEN-RING STATISTICS (tok0) :
Device Type: IBM PCI Tokenring Adapter (14103e00)
Hardware Address: 00:20:35:7a:12:8a
Elapsed Time: 29 days 18 hours 3 minutes 47 seconds

Transmit Statistics: Receive Statistics:
-------------------- -------------------
Packets: 1355364 Packets: 55782254
Bytes: 791555422 Bytes: 6679991641
Interrupts: 902315 Interrupts: 55782192
Transmit Errors: 0 Receive Errors: 1
Packets Dropped: 0 Packets Dropped: 0
Bad Packets: 0
Max Packets on S/W Transmit Queue: 182
S/W Transmit Queue Overflow: 42
Current S/W+H/W Transmit Queue Length: 0

Broadcast Packets: 18878 Broadcast Packets: 54615793
Multicast Packets: 0 Multicast Packets: 569
Timeout Errors: 0 Receive Congestion Errors: 0
Current SW Transmit Queue Length: 0
Current HW Transmit Queue Length: 0

General Statistics:
-------------------
No mbuf Errors: 0 Lobe Wire Faults: 0
Abort Errors: 12 AC Errors: 0
Burst Errors: 1 Frame Copy Errors: 0
Frequency Errors: 0 Hard Errors: 0
Internal Errors: 0 Line Errors: 0
Lost Frame Errors: 0 Only Station: 1
Token Errors: 0 Remove Received: 0
Ring Recovered: 17 Signal Loss Errors: 0
Soft Errors: 35 Transmit Beacon Errors: 0
Driver Flags: Up Broadcast Running
AlternateAddress 64BitSupport ReceiveFunctionalAddr
16 Mbps

IBM PCI Tokenring Adapter (14103e00) Specific Statistics:
---------------------------------------------------------
Media Speed Running: 16 Mbps Half Duplex
Media Speed Selected: 16 Mbps Full Duplex
Receive Overruns : 0
Transmit Underruns : 0
ARI/FCI errors : 0
Microcode level on the adapter :001PX11B2
Num pkts in priority sw tx queue : 0
Num pkts in priority hw tx queue : 0
Open Firmware Level : 001PXRS02

下面要讲的是高亮显示的字段：

* 发送和接收错误

这个设备所遇到的输入 / 输出错误数量。这个字段统计所有由于硬件或是网络故障造成的不成功发送的次数。

发送不成功也可以降低系统的性能。
* S/W 发送队列上的最大信息包

曾经在软件发送队列中排队等待的外发信息包的最大数量。

如果排队等待的最大发送量和当前队列的大小（xmt_que_size）相等，这表明队列的大小不合适。这表明队列在某个点上已经全满。

为了检查队列的当前大小，可以使用 lsattr -El 适配器命令（比如，这里的适配器可以 tok0 或是 ent0）。因为队列是和设备驱动程序与接口的适配器相关联的，所以要使用适配器名称，而不是接口名称。使用 SMIT 或者 chdev 命令可以改变队列的大小。
* S/W 发送队列溢出

外发信息包的数量从软件发送队列中溢出。除零以外的任何值和当 S/W 发送队列的最大信息包达到 xmt_que_size 值的情况都需要同样的操作。必须增加发送队列的大小。
* 广播信息包

广播信息包的数目接收无误。

如果广播信息包的值较高，就把它和接收信息包的总数相比较。接收到的广播信息包应该比接收到的信息包总量的 20% 还要小。如果其值较高，可能暗示着网络的负载较重，在使用多点传送。使用 IP 多点传送可以把信息发送到一组主机上，而不需要对每一个工作组成员进行地址标记和单独发送信息。
* DMA 超限

当适配器使用 DMA 把信息包放入系统存而且传输过程没有终止时， DMA 超限统计信息会进行增一操作。有可用的系统缓冲区可以放入信息包，但 DMA 操作不能完成。当 MCA 总线对于适配器来说过于繁忙，不能够对信息包使用 DMA 时会出现这种情况。在一个重负载的系统中，适配器在总线上的位置是很关键的。标准情况下，总线上较低插槽号的适配器由于拥有较高的总线优先权，使用的总线量很大，以至于在较高插槽号的适配器不能接收到服务。尤其是当较低插槽的适配器是 ATM 或是 SSA 适配器时，更是这种情况。
* 最大冲突错误

由于过多冲突导致的不成功发送的次数。遇到的冲突次数超过了适配器上的重试次数。
* 最近的冲突错误

由于上次冲突错误造成的不成功发送的数量。
* 超时错误

由于适配器报告超时错误导致的不成功发送的数目。
* 单独冲突计数

在发送过程中有单独冲突的外发信息包数量。
* 多路冲突计数

在发送过程中有多路冲突的外发信息包数量。
* 接收冲突错误

在接收过程中有冲突错误的接入信息包的数量。
* 无 mbuf 错误

设备驱动程序没有可用 mbuf 的次数统计。这通常发生在接收操作中，驱动程序必须存缓冲区来处理入站信息包的情况下。如果所请求大小的 mbuf 池为空，这个信息包就会被删除。可以使用 netstat -m 命令来进行验证，增加 thewall 的参数值。

No mbuf Errors 的值是由接口指定的，和被拒绝的 mbuf 请求不一样（在 netstat -m 命令的输出中）。比较使用 netstat -m 命令和 netstat -v 命令（以太网和 Token-Ring 部分）的值。

为了确定网络性能问题，检查所有的错误输出（在 netstat -v 命令的输出中）。

附加的准则：

* 为了检查过载的以太网络，要做一些计算（从 netstat -v 命令中）：

（最大冲突错误 + 超时错误）/ 发送信息包量

如果结果大于 5%，就需要重新改组网络来平衡负载。
* 高网络负载也表明了另一种情况（从 netstat -v 命令中）：

如果 netstat -v 命令输出（对于以太网）中的冲突总量大于总传输