【导读】出现性能问题的时候，您的系统可能一点过失也没有，而真正的故障原因却是外面的建筑物。如果要知道是否是网络影响总体的性能，一个简单的方法就是比较涉及网络的操作和那些和网络无关的操作。
如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。一些潜在的网络瓶颈可能由以下因素造成：
* 客户端网络接口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
.
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 144834 0 144946 0 0
lo0 16896 127 localhost 144834 0 144946 0 0
tr0 1492 10.0.5a.4f.3f.61 658339 0 247355 0 0
tr0 1492 9.3.1 ah6000d 658339 0 247355 0 0
en0 1500 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
下面的例子显示的是 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 命令输出（对于以太网）中的冲突总量大于总传输信息包量的 10%，如下所示：
冲突数量 / 发送的信息包量 > 0.1
netstat -p protocol
显示由协议参量（udp、tcp、ip、icmp）所指定值的统计信息，要么是一个协议所熟悉的名称要么是它的一个代名。在 /etc/protocols 文件中列出了一些协议名称和它们的代名。一个空响应表明，没有要报告的数据。如果没有统计程序，那么协议参量指定值的程序报告就是不可知的。
下面的例子显示的是 ip 协议的输出：
# netstat -p ip
ip:
:
491351 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
25930 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
12965 packets reassembled ok
475054 packets for this host
0 packets for unknown/unsupported protocol
0 packets forwarded
3332 packets not forwardable
0 redirects sent
405650 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
5498 output datagrams fragmented
10996 fragments created
0 datagrams that cant be fragmented
0 IP Multicast packets dropped due to no receiver
0 ipintrq overflows
下面要提到的是高亮显示的部分：
* 接收到的信息包总量
接收到的 IP 数据报总数。
* 无效报头校验和或删除的段
如果输出表明无效报头校验和 或 删除段 是由于重复或超出空间造成的，这就表明网络传输信息包出现谬误或是设备驱动程序接收信息包的队列没有足够大。
* 收到的段
收到的段总数。
* 超时后删除的段
如果超时后删除的段为非零，那么 ip 段的计数时间在所有的数据报段到达之前就会因为网络繁忙而终止。为了避免这种情况，可以使用 no 命令来提高 ipfragttl 的网络参数值。另一个原因可能是 mbuf 的不足造成的，这就要增加 thewall的参数值。
* 从该主机发送的信息包
由这个系统创建并发送出去的 IP 数据报数目。这个计数不包括转发的数据报（由流量转发）。
* 创建的段
发送 IP 数据报时系统中创建的段的数目。
查看 IP 的统计量时，参阅一下收到的信息包和收到的分段的比率。对于小的 MTU 网络有一个准则，如果有 10% 或者更多的信息包进行了分段，那么您就应该进一步调查以确定其原因。如果有很大数量的分段，那表明远程主机 IP 层上的协议正在向 IP 传输比接口的 MTU 值要大的数据。网络路径中的网关或路由器可能也有比网络中其他节点小得多的 MTU 值。对于发送的信息包和创建的段这也同样适用。
分段会导致 CPU 的额外负载，所以确定它的起因很重要。要知道一些应用程序本身就能够导致分段。比如，一个发送小数量数据的应用程序就能够导致出现分段。然而，如果您知道应用程序正在发送大量的数据，同时仍然出现分段，就需要确定它的起因。然而，如果您知道应用程序正在发送大量的数据，同时仍然出现分段，就需要确定它的起因。可能是因为使用的 MTU 大小不是系统中所配置的 MTU 大小。
下面的例子显示的是 udp 协议的输出：
# netstat -p udp
udp:
11521194 datagrams received
0 incomplete headers
0 bad data length fields
0 bad checksums
16532 dropped due to no socket
232850 broadcast/multicast datagrams dropped due to no socket
77 socket buffer overflows
11271735 delivered
796547 datagrams output
下面是重要的统计量：
* 无效校验和
无效校验和可能是由于硬件板卡或是电缆故障造成的。
* 由于无套接字导致的删除
那些没有打开端口的套接字所接收到的 UDP 数据报总数。因而，肯定会发送 ICMP 目标地址无法到达 - 端口无法到达的信息。但是如果收到的 UDP 数据报是广播数据报，就不会产生 ICMP 错误。如果这个值较高，就需要检查应用程序如何如何处理套接字的。
* 套接字缓冲区溢出
套接字缓冲区溢出可能是由以下原因造成：发送和接收 UDP 套接字不足、nfsd 守护程序太少或者是 nfs_socketsize、udp_recvspace 和 sb_max 值太小。
如果 netstat -p udp 命令表示套接字溢出，那么您或许需要增加服务器端 nfsd 守护程序的数量。首先，检查受 CPU 或 I/O 饱和度影响的系统，并使用 no -a 命令来检验其他通信层的推荐设置。如果系统处于饱和状态，那么您必须降低它的负载或是增加资源。
下面的例子显示的是 tcp 协议的输出：
# netstat -p tcp
tcp:
63726 packets sent
34309 data packets (6482122 bytes)
198 data packets (161034 bytes) retransmitted
17437 ack-only packets (7882 delayed)
0 URG only packets
0 window probe packets
3562 window update packets
8220 control packets
71033 packets received
35989 acks (for 6444054 bytes)
2769 duplicate acks
0 acks for unsent data
47319 packets (19650209 bytes) received in-sequence
182 completely duplicate packets (29772 bytes)
4 packets with some dup. data (1404 bytes duped)
2475 out-of-order packets (49826 bytes)
0 packets (0 bytes) of data after window
0 window probes
800 window update packets
77 packets received after close
0 packets with bad hardware assisted checksum
0 discarded for bad checksums
0 discarded for bad header offset fields
0 connection request
3125 connection requests
1626 connection accepts
4731 connections established (including accepts)
5543 connections closed (including 31 drops)
62 embryonic connections dropped
38552 segments updated rtt (of 38862 attempts)
0 resends due to path MTU discovery
3 path MTU discovery terminations due to retransmits
553 retransmit timeouts
28 connections dropped by rexmit timeout
0 persist timeouts
464 keepalive timeouts
26 keepalive probes sent
1 connection dropped by keepalive
0 connections in timewait reused
0 delayed ACKs for SYN
0 delayed ACKs for FIN
0 send_and_disconnects
所关心的统计信息是：
* 发送的信息包
* 信息包
* 重新传送的信息包
* 接收到的信息包
* 完全重复的信息包
* 重新传送超时
对于 TCP 统计信息，比较发送的信息包数和重发的信息包数。如果重发的信息包数大于总发送信息包量的 10-15%，TCP 就会出现超时，这表明网络流量负载很大，在超时之前不能返回应答信号（ACK）。接收的网节点的瓶颈或是一般的网络故障也会导致 TCP 重发，这会增大网络流量，给网络性能带来了进一步的问题。
同样，需要比较接收到的信息包量和完整复制的信息包量。如果在发送网节点上的 TCP 在从接收节点收到 ACK 信号之前就已经超时，它会重发这个信息包。当接收节点最终接收到所有重发的信息包时会进行复制。如果复制信息包的数量超出了 10-15%，那么这个问题可能还是由于网络流量过大或是接收节点的瓶颈问题所造成的。复制信息包会增加网络流量。
如果 TCP 发出一个信息包但没有按时接收到 ACK 信号，就会生成重发超时的一个量。然后它会重新发送信息包。以后每次重发这个量都会执行增一操作。这些持续的重发操作使得 CPU 的利用率更高，而且如果接收节点没有收到信息包，它最终会被删除掉。
netstat -s
netstat -s 命令显示的是每个协议的统计量（而 netstat -p 命令显示的是指定协议的统计量）。
netstat -s -s
没有正式加以说明的 -s -s 参数项显示的只是 netstat -s 命令输出中不是零的那些行，这样就可以更容易找到错误的统计。
netstat -s -Z
这是 netstat 命令没有正式说明的功能。它把 netstat -s 命令的所有统计计数器都进行清零。
netstat -r
另一个和性能相关的参数项是人们定义的最大路径发送单元（PMTU）的显示。
对于两个通过多重网络路径通信的主机来说，如果发送的信息包比路径重任何一个网路的最小 MTU 值要大，就会对这个信息包进行分段。因为信息包的分段会导致网络性能的下降，所以一般期望的是采用发送比网络路径重最小的 MTU 还要小的信息包，从而来避免出现分段。这个大小称为是路径 MTU。
通过使用 netstat -r 命令可以显示这个值。下面是一个例子，使用 netstat -r -f inet 命令来显示路由表：
# netstat -r -f inet
Routing tables
Destination Gateway Flags Refs Use PMTU If Exp Groups
Route Tree for Protocol Family 2:
default itsorusi UGc 1 348 - tr0 -
9.3.1 sv2019e Uc 25 12504 - tr0 -
itsonv sv2019e UHW 0 235 - tr0 -
itsorusi sv2019e UHW 1 883 1492 tr0 -
ah6000d sv2019e UHW 1 184 1492 tr0 -
ah6000e sv2019e UHW 0 209 - tr0 -
sv2019e sv2019e UHW 4 11718 1492 tr0 -
coyote.ncs.mainz itsorusi UGHW 1 45 1492 tr0 -
127 localhost U 3 96 - lo0 -
netstat -D
您可以使用 -D 参数项来查看在通信子系统每一层中删除信息包的同时，每一层进入和导出的信息包。
# netstat -D
Source Ipkts Opkts Idrops Odrops
-------------------------------------------------------------------------------
tok_dev0 19333058 402225 3 0
ent_dev0 0 0 0 0
---------------------------------------------------------------
Devices Total 19333058 402225 3 0
-------------------------------------------------------------------------------
tok_dd0 19333055 402225 0 0
ent_dd0 0 0 0 0
---------------------------------------------------------------
Drivers Total 19333055 402225 0 0
-------------------------------------------------------------------------------
tok_dmx0 796966 N/A 18536091 N/A
ent_dmx0 0 N/A 0 N/A
---------------------------------------------------------------
Demuxer Total 796966 N/A 18536091 N/A
-------------------------------------------------------------------------------
IP 694138 677411 7651 6523
TCP 143713 144247 0 0
UDP 469962 266726 0 812
---------------------------------------------------------------
Protocols Total 1307813 1088384 7651 7335
-------------------------------------------------------------------------------
lo_if0 22088 22887 799 0
tr_if0 796966 402227 0 289
---------------------------------------------------------------
Net IF Total 819054 425114 799 289
-------------------------------------------------------------------------------
---------------------------------------------------------------
NFS/RPC Total N/A 1461 0 0
-------------------------------------------------------------------------------
（注解：N/A -> 不可用）
设备层显示的是进入适配器的信息包数量、导出适配器的信息包数量和在输入输出端口丢失的信息包量。适配器错误有各种各样的原因，使用 netstat -v 命令可以查看更多的细节内容。
驱动程序层显示了设备驱动程序为每一个适配器处理的信息包量。这时 netstat -v 命令可以用来帮助确定统计的是哪一种错误。
多路分离器的值显示的是多路分离层中统计的信息包数量，而且这儿的 Idrops 通常表示滤波使得信息包被删除（比如，Netware 或 DecNet 信息包就是因为它们没有被正在检测的系统所处理才被删除的）。
要查看协议层的详细内容，请参阅netstat -s 命令的输出。
注:
在统计结果的输出中，在字段值中显示的 N/A 表示不可用。对于 NFS/RPC 部分而言，经由 RPC 的进入信息包和经由 NFS 的信息包是一样的，这样这些数量就不会被加入到 NFS/RPC 总和字段中去，因而是 N/A。NFS 没有流出的信息包或是没有指定给 NFS 和 RPC 的流出信息包丢失计数器。因而，各自的计数器都有对 N/A 的字段值，而且累计计数存放在 NFS/RPC 总和字段中。
netpmon 命令
netpmon 命令使用跟踪工具可以得到在一个时间间隔内网络操作的详细内容。因为它使用了跟踪工具，所以 netpmon 只能由根用户或是系统工作组的某个成员运行。
而且，netpmon 命令不能和其他任何基于跟踪的性能命令同时运行，比如 tprof 和 filemon。在它的通常模式下，netpmon 命令一般在运行监控一个或多个应用程序或是系统命令时运行。
netpmon 命令主要是针对下面的系统动作：
* CPU 使用状况
o 进程和中断处理程序
o 有多少程序和网络相关联
o 造成空闲状态的原因
* 网络设备驱动 I/O 端口
o 通过所有的以太网、Token-Ring 和光纤分布数据接口网络设备驱动来检测对 I/O 端口的操作。
o 在 I/O 端口传输的情况下，命令监控使用状况、队列长度和目标主机。对于接收到的标识，命令也会监控多路分离层的时间。
* 网络套接字调用
o 监控网络套接字上的 send()、recv()、sendto()、recvfrom()、sendmsg()、read() 和 write() 子程序。
o 在预处理的基础上通报因特网控制信息协议（ICMP）、传输控制协议（TCP）和用户数据报协议（UDP）的统计量。
* NFS I/O 端口
o 客户端：RPC 请求、NFS 读取 / 写入请求。
o 服务器端：每客户端、每文件、读取 / 写入请求。
下面列出的是要计算的量：
* 在设备驱动级别上和发送 / 接收操作相关联的响应时间和大小。
* 和所有类型的网络套接字读取 / 写入系统调用相关联的响应时间和大小。
* 和 NFS 读取写入系统调用相关联的响应时间和大小。
* 和 NFS 远程过程调用请求相关联的响应时间。
为了确定 netpmon 命令是否已安装而且可用，可以运行如下命令：
# lslpp -lI perfagent.tools
使用 netpmon 命令可以启动跟踪过程，可选用 trcoff 子命令进行暂挂，选用 trcon 子命令继续进行，终止跟踪采用 trcstop 子命令。一旦跟踪过程终止，netpmon 命令就把它的通报送到标准输出单元。
netpmon 的使用
netpmon 命令可以立即启动跟踪（除非使用了 -d 可选项）。使用 trcstop 命令可以终止跟踪。那时可以生成所有的指定报告，而且会退出 netpmon 命令。在客户 - 服务器模式下，使用 netpmon 命令可以查看网络怎样影响总体性能。它可以在客户和服务器端运行。
netpmon 命令能够从指定文件中读取 I/O 跟踪数据，而不是从实时的跟踪过程中读取。这种情况下，netpmon 的报告就以文件的形式对系统这个时段的网络操作进行了概括。当需要从远程主机上对跟踪文件进行过程后处理或者，一段时间执行记录跟踪数据，另一段时间用来对它进行过程后处理，这时这种脱机处理的方法就很有用处。
trcrpt -r 命令必须在跟踪记录文件上执行，并导向另一个文件，如下所示：
# gennames > gennames.out
# trcrpt -r trace.out > trace.rpt
这时，一个调整过的跟踪记录文件送进 netpmon 命令来通报由上一个被记录的跟踪进程所捕捉到的 I/O 端口动作，如下所示：
# netpmon -i trace.rpt -n gennames.out | pg
在这个示例中，netpmon 命令从输入文件 trace.rpt 中读取文件系统跟踪事件。因为跟踪数据已经捕捉到文件中，netpmon 命令并不把它放到后台以便让应用程序运行。读取全部文件之后，在标准输出单元上会显示网络操作的通报（在本例中是导出到 pg 命令）。
如果 trace 命令是带 -C all 标记运行，那么运行 trcrpt 命令时也要带有 -C all 标记（请参阅『跟踪 -C 输出报告的格式』）。
下面的 netpmon 命令是在一台 NFS 服务器上运行，它执行 sleep 命令并在 400 秒后创建一个报告。在测定的间隔内，就生成了一个到安装有 NFS 文件系统 /nfs_mnt 的备份。
# netpmon -o netpmon.out -O all; sleep 400; trcstop
如果有 -O 参数项，您就可以指定要生成的报告类型。有效的报告类型值有：
cpu
CPU 使用状况
dd
网络设备驱动 I/O 端口
so
网络套接字 I/O 端口调用
nfs
NFS I/O 端口
all
这样就生成了所有的报告。下面列出的是缺省值。
# cat netpmon.out
Thu Jan 21 15:02:45 2000
System: AIX itsosmp Node: 4 Machine: 00045067A000
401.053 secs in measured interval
========================================================================
Process CPU Usage Statistics:
-----------------------------
Network
Process (top 20) PID CPU Time CPU % CPU %
----------------------------------------------------------
nfsd 12370 42.2210 2.632 2.632
nfsd 12628 42.0056 2.618 2.618
nfsd 13144 41.9540 2.615 2.615
nfsd 12886 41.8680 2.610 2.610
nfsd 12112 41.4114 2.581 2.581
nfsd 11078 40.9443 2.552 2.552
nfsd 11854 40.6198 2.532 2.532
nfsd 13402 40.3445 2.515 2.515
lrud 1548 16.6294 1.037 0.000
netpmon 15218 5.2780 0.329 0.000
gil 2064 2.0766 0.129 0.129
trace 18284 1.8820 0.117 0.000
syncd 3602 0.3757 0.023 0.000
swapper 0 0.2718 0.017 0.000
init 1 0.2201 0.014 0.000
afsd 8758 0.0244 0.002 0.000
bootpd 7128 0.0220 0.001 0.000
ksh 4322 0.0213 0.001 0.000
pcimapsvr.ip 16844 0.0204 0.001 0.000
netm 1806 0.0186 0.001 0.001
----------------------------------------------------------
Total (all processes) 358.3152 22.336 20.787
Idle time 1221.0235 76.114
========================================================================
First Level Interrupt Handler CPU Usage Statistics:
---------------------------------------------------
Network
FLIH CPU Time CPU % CPU %
----------------------------------------------------------
PPC decrementer 9.9419 0.620 0.000
external device 4.5849 0.286 0.099
UNKNOWN 0.1716 0.011 0.000
data page fault 0.1080 0.007 0.000
floating point 0.0012 0.000 0.000
instruction page fault 0.0007 0.000 0.000
----------------------------------------------------------
Total (all FLIHs) 14.8083 0.923 0.099
========================================================================
Second Level Interrupt Handler CPU Usage Statistics:
----------------------------------------------------
Network
SLIH CPU Time CPU % CPU %
----------------------------------------------------------
tokdd 12.4312 0.775 0.775
ascsiddpin 0.5178 0.032 0.000
----------------------------------------------------------
Total (all SLIHs) 12.9490 0.807 0.775
========================================================================
Network Device-Driver Statistics (by Device):
---------------------------------------------
----------- Xmit ----------- -------- Recv ---------
Device Pkts/s Bytes/s Util QLen Pkts/s Bytes/s Demux
------------------------------------------------------------------------------
token ring 0 31.61 4800 1.7% 0.046 200.93 273994 0.0080
========================================================================
Network Device-Driver Transmit Statistics (by Destination Host):
----------------------------------------------------------------
Host Pkts/s Bytes/s
----------------------------------------
ah6000c 31.57 4796
9.3.1.255 0.03 4
itsorusi 0.00 0
========================================================================
TCP Socket Call Statistics (by Process):
----------------------------------------
------ Read ----- ----- Write -----
Process (top 20) PID Calls/s Bytes/s Calls/s Bytes/s
------------------------------------------------------------------------
telnetd 18144 0.03 123 0.06 0
------------------------------------------------------------------------
Total (all processes) 0.03 123 0.06 0
========================================================================
NFS Server Statistics (by Client):
----------------------------------
------ Read ----- ----- Write ----- Other
Client Calls/s Bytes/s Calls/s Bytes/s Calls/s
------------------------------------------------------------------------
ah6000c 0.00 0 31.54 258208 0.01
------------------------------------------------------------------------
Total (all clients) 0.00 0 31.54 258208 0.01
========================================================================
Detailed Second Level Interrupt Handler CPU Usage Statistics:
-------------------------------------------------------------
SLIH: tokdd
count: 93039
cpu time (msec): avg 0.134 min 0.026 max 0.541 sdev 0.051
SLIH: ascsiddpin
count: 8136
cpu time (msec): avg 0.064 min 0.012 max 0.147 sdev 0.018
COMBINED (All SLIHs)
count: 101175
cpu time (msec): avg 0.128 min 0.012 max 0.541 sdev 0.053
========================================================================
Detailed Network Device-Driver Statistics:
------------------------------------------
DEVICE: token ring 0
recv packets: 80584
recv sizes (bytes): avg 1363.6 min 50 max 1520 sdev 356.3
recv times (msec): avg 0.081 min 0.010 max 0.166 sdev 0.020
demux times (msec): avg 0.040 min 0.008 max 0.375 sdev 0.040
xmit packets: 12678
xmit sizes (bytes): avg 151.8 min 52 max 184 sdev 3.3
xmit times (msec): avg 1.447 min 0.509 max 4.514 sdev 0.374
========================================================================
Detailed Network Device-Driver Transmit Statistics (by Host):
-------------------------------------------------------------
HOST: ah6000c
xmit packets: 12662
xmit sizes (bytes): avg 151.9 min 52 max 184 sdev 2.9
xmit times (msec): avg 1.448 min 0.509 max 4.514 sdev 0.373
HOST: 9.3.1.255
xmit packets: 14
xmit sizes (bytes): avg 117.0 min 117 max 117 sdev 0.0
xmit times (msec): avg 1.133 min 0.884 max 1.730 sdev 0.253
HOST: itsorusi
xmit packets: 1
xmit sizes (bytes): avg 84.0 min 84 max 84 sdev 0.0
xmit times (msec): avg 0.522 min 0.522 max 0.522 sdev 0.000
========================================================================
Detailed TCP Socket Call Statistics (by Process):
-------------------------------------------------
PROCESS: telnetd PID: 18144
reads: 12
read sizes (bytes): avg 4096.0 min 4096 max 4096 sdev 0.0
read times (msec): avg 0.085 min 0.053 max 0.164 sdev 0.027
writes: 23
write sizes (bytes): avg 3.5 min 1 max 26 sdev 7.0
write times (msec): avg 0.143 min 0.067 max 0.269 sdev 0.064
PROTOCOL: TCP (All Processes)
reads: 12
read sizes (bytes): avg 4096.0 min 4096 max 4096 sdev 0.0
read times (msec): avg 0.085 min 0.053 max 0.164 sdev 0.027
writes: 23
write sizes (bytes): avg 3.5 min 1 max 26 sdev 7.0
write times (msec): avg 0.143 min 0.067 max 0.269 sdev 0.064
========================================================================
Detailed NFS Server Statistics (by Client):
-------------------------------------------
CLIENT: ah6000c
writes: 12648
write sizes (bytes): avg 8187.5 min 4096 max 8192 sdev 136.2
write times (msec): avg 138.646 min 0.147 max 1802.067 sdev 58.853
other calls: 5
other times (msec): avg 1.928 min 0.371 max 8.065 sdev 3.068
COMBINED (All Clients)
writes: 12648
write sizes (bytes): avg 8187.5 min 4096 max 8192 sdev 136.2
write times (msec): avg 138.646 min 0.147 max 1802.067 sdev 58.853
other calls: 5
other times (msec): avg 1.928 min 0.371 max 8.065 sdev 3.068
netpmon 命令的输出由两种不同类型的报告组成：总体报告和细节报告。下面列出的是总体报告列表信息：
* 大多数正在运行的过程
* 第一级别的中断处理程序
* 第二级别的中断处理程序
* 网络设备驱动程序
* 网络设备驱动程序发送
* TCP 套接字调用
* NFS 服务器或者客户端信息
在 netpmon 输出的开头显示的是总体报告，是在测量间隔中发生的情况。细节性报告提供了总体性报告的附加信息。缺省情况下，报告受限于最多只能有 20 个有效的测量信息。报告中的所有信息都从顶到底依次列出，也是从最有效的到次有效的。
netpmon 的总体报告
采用 netpmon 命令所生成的报告开始部分是一个报头，它标明了日前，主机的标识，和监控时间段的长度（以秒为单位）。报头后面是对所有指定报告类型的总体报告和细节性报告集。
进程的 CPU 使用情况
每一行描述的都是和一个进程相关的 CPU 使用情况。除非指定了‘详细’（ -v）这个可选项，否则在列表中只能包括最多 20 个有效的过程。在报告的末尾，对所有过程的 CPU 使用状况进行了统计叠加，并通报了 CPU 的空闲时间。空闲时间的百分比数值可以通过把空闲时间去除测量间隔，经过计算得到。CPU 的总时间和测量间隔的不同是由于中断处理程序造成的。
网络 CPU 百分比 是用来执行和网络相关代码所占用的总时间的百分比。
如果使用了 -t 标记，就会生成一个 CPU 使用状况信息的线程。上面提到的每一个进程行都紧跟在该进程所有每个描述 CPU 使用状况的行后面。这些行中的字段和进程中的字段是一致的，名称字段除外。线程没有命名。
在报告的例子中，CPU 使用的总体报告中显示的空闲时间百分比数值（76.114 %）是通过 空闲时间（1221.0235）被测量间隔的 4 倍（401.053 乘 4，因为服务器中有 4 个 CPU），经过计算得到。如果您想查看每个 CPU 的行为，您可以使用 sar、ps 或者任何其他的 SMP 的具体命令。类似的计算同样适用于被所有进程所占用的总共的 CPU %。空闲时间是由于网络 I/O 端口造成的。CPU 时间的总和（1221.0235 + 358.315）和测量间隔的不同是由于中断处理程序和多 CPU 造成的。从报告实例上可以看出，大多数的 CPU 使用状况都是和网络相关的：（20.787 / 22.336） = 93.07 %。大约有 77.664% 的 CPU 使用是由 CPU 空闲程序或是 CPU 等待时间构成。
注:
总网络 CPU 百分比被总 CPU 百分比去除，得到的结果如果大于 0.5（从用于 NFS 服务器的 CPU 进程使用信息可以看出），那么 CPU 的大多数使用都是和网络相关的。
这个方法也是查看 CPU 进程使用状况的好方法，不需要把输出连接到一个指定程序上。
第一级别的中断处理程序占用 CPU 信息统计
每一行都是和第一级别中断处理程序（FLIH）相关联的 CPU 使用情况。在报告的末尾，对所有 FLIH 对 CPU 的占用情况进行了求和。
CPU 计时
这个 FLIH 所使用的 CPU 计时的总和
CPU %
这个中断处理程序对 CPU 的使用占总计时的百分比
网络 CPU %
该中断处理程序由于执行网络相关事件所占用总计时的百分比
第二级别中断处理对 CPU 的使用状况信息
每一行描述的都是和第二级别中断处理程序相关的 CPU 占用情况（SLIH）。在报告的末尾，对所有 SLIH 对 CPU 的使用进行了求和。
网络设备驱动信息（设备）
每一行描述的都是和网络设备相关的信息。
设备
和设备相关的特殊文件的名称
Xmit Pkts/s
每秒钟通过该设备嘎送的信息包数
Xmit Bytes/s
每秒通过该设备发送的字节数
Xmit Util
设备的繁忙时间，是占总计时的百分比
Xmit Qlen
等待经由该设备传输的请求的数量，它是在时间上的平均，包括当前正在传输的部分
Recv Pkts/s
每秒钟经由该设备所接收到的信息包
Recv Bytes/s
每秒钟经由该设备所接收到的字节数
Recv Demux
在多路分离层中所花费的时间，是总计时的一部分
在本例中，Xmit QLen 的值仅为 0.046。这个数值和它的缺省大小（30）相比是非常小的。它的 Recv Bytes/s 为 273994，比 Token-Ring 传输速率要小很多。因而，在这种情况下，网络处于不饱和状态，至少从系统的角度看是这样。
网络设备驱动传输信息（通过目标主机）
每一行描述的都是在设备驱动级别上和特定的目标主机相关联的传输流量的数目。
Host
目标主机名称。使用星号（*）来表示没有确定主机名称的传输。
Pkts/s
每秒钟发送到这个主机上的信息包数量。
Bytes/s
每秒钟发送到这个主机上的字节数。
每个网络协议中的 TCP 套接字调用信息（通过进程）。
使用的每个网络协议都有信息显示。每一行都描述了和指定进程相关联的这个协议类型的套接字上的 read() 和 write() 子程序的数量。在报告的末尾部分，对该协议的所有套接字调用进行了求和。
NFS 服务器信息（通过客户端）
每一行描述的是由服务器处理的 NFS 动作的数目，它代表的是具体的客户端。在报告的末尾部分，对所有的客户端进行了求和。
在客户机上，NFS 服务器信息被 NFS 客户信息（每个服务器的 NFS 客户信息（文件）、NFS 客户端 RPC 信息（服务器）、NFS 客户信息（进程））所替换。
netpmon 的细节性报告
细节性报告是为所有受请求（-O）报告类型而产生的。对于这些报告类型，除了总体报告之外还有细节性报告。总体报告中对于每种类型的事务都有一个入口相关，对于总体报告中的每一个入口，细节性报告都含有一个入口。 The detailed reports contain an entry for each entry in the global reports with statistics for each type of transaction associated with the entry.
事务统计量包括该类型的事务数量统计（在响应时间和大小数据分布（如果适用）之后）。分布信息包括均值、最小值和最大值，还有标准差。大约有三分之二的数据在平均值、标准差二者之差和二者之和之间。大小以字节为单位进行通报。响应时间以毫秒单位进行通报。
细节性的第二级别中断处理程序对 CPU 使用的统计量
下面要讲的是输出的字段：
SLIH
第二级别的中断处理程序的名称
counts
该类型的中断数量
cpu 计时（毫秒）
该类型的中断处理程序对 CPU 的使用统计量
详细的网络设备驱动统计量（设备）
下面要提到的是输出的字段：
设备
和设备相关联的特殊文件的路径名
recv packets
通过该设备接收到的信息包数量
recv sizes (bytes)
接收到的信息包大小统计
recv times (msec)
处理接收到的信息包所需要的回应时间统计
demux times (msec)
在多路分离层中处理接收到的信息包所需要的时间统计
xmit packets
由该设备所发送的信息包数量
xmit sizes (bytes)
发送信息包的大小统计
xmit times (msec)
处理发送信息包所需要的回应时间统计
还有其他的详细报告，比如详细的网络设备驱动发送统计（主机）和每个网络协议的详细 TCP 套接字调用统计（进程）。对于每一个 NFS 客户端来说，都有对每个服务器的详细 NFS 客户统计（文件）、详细 NFS 客户端 RPC 统计（服务器）和详细 NFS 客户端统计（进程）报告。对于每个 NFS 服务器而言，有详细 NFS 服务器统计（客户）报告。它们有相同的输出字段，如上面解释的一样。
在实例中，从详细网络设备驱动统计可以得到以下内容：
* recv bytes = 80584 packets * 1364 bytes/packet = 109,916,576 bytes
* xmit bytes = 12678 packets * 152 bytes/packet = 1,927,056 bytes
* total bytes exchanged = 109,916,576 + 1,927,056 = 111,843,632 bytes
* total bits exchanged = 111,843,632 * 8 bits/byte = 894,749,056 bits
* transmit speed = 894,749,056 / 401.053 = 2.23 Mb/s（假定复制过程占据了监控的全部时间）
和在总体设备驱动报告中一样，您可以得出这种情况也不是网络饱和状态。接收大小的均值是 1363.6 字节，接近缺省的 MTU（最大发送单元）值，设备为 Token-Ring 板卡时缺省值时 1492。如果这个值比 MTU 值要大（lsattr -E -l 接口，使用接口名称替换接口，比如 en0 或是 tr0），您可以使用下面的命令改变 MTU 的值或是适配器发送队列长度，从而可以获取更好的性能：
# ifconfig tr0 mtu 8500
or
# chdev -l tok0 -a xmt_que_size=150
如果网络已经阻塞，改变 MTU 或是队列值都不会有所帮助。
注:
1. 如果在设备驱动统计报告中发送和接收的信息包大小较小，那么增大当前的 MTU 大小或许会改善网络性能。
2. 如果从 NFS 客户端报告的网络等待时间看出，系统由于网络调用的原因造成等待时间长，那么这种不良性能是由于网络造成的。
netpmon 的限制
netpmon 命令使用跟踪工具来收集统计量。因而，它对系统的工作负载有影响，如下所示。
* 在适度、网络基准的工作负载下，netpmon 命令使总体的 CPU 使用情况增加了 3-5 个百分点。
* 在 CPU 饱和而且几乎没有任何 I/O 端口的情况下，netpmon 命令使大的编译程序降慢了大约 3.5 个百分点。
为了减轻这些状况，可以使用脱机处理，在有多个 CPU 的系统上可以使用-C all 标记和 trace 命令。
跟踪路由命令
虽然ping 命令可以验证是否能够到达 IP 网络，但您不能够对一些单独的问题进行精确定位和改善。请考虑下面的情况：
* 如果在您的主机和目标地址之间有很多转发单元（比如，网关或是路由），而且在沿路径的某处好像有问题存在。目标地址的系统可能有问题，但是您需要知道信息包实际上在哪儿丢失的。
* ping 命令会终止，但不会告诉您信息包丢失的缘由。
traceroute 命令可以告诉您信息包的位置，也能告诉您为什么路由会丢失。如果您的信息包必须通过路由器和链接，而这些都是属于其他组织或是公司并且由它们来管理，那么要通过 telnet 命令来检查相关的路由器就很困难。traceroute 命令为 ping 命令提供了一个追加功能。
注:
traceroute 命令可以用来做网络测试、测量和管理。它主要用于手动故障隔离。由于它对网络施加了负载，所以在标准的操作或是自动运行的脚本下不要使用 traceroute 命令。
成功跟踪路由的实例
traceroute 命令使用 UDP 信息包和 ICMP 错误通报功能。它发送 3 次 UDP 信息包，发送到路径上的每一个网关或路由器上。它从最近的网关开始启动，通过转发扩展搜索。最后，搜索到了目标系统。在输出中，您可以看到网关名称、网关的 IP 地址和 网关 3 次往返的时间。请看下面的例子：
# traceroute wave
trying to get source for wave
source should be 9.53.155.187
outgoing MTU = 1500
1 9.111.154.1 (9.111.154.1) 5 ms 3 ms 2 ms
2 wave (9.53.153.120) 5 ms 5 ms 5 ms
下面是另一个例子：
# traceroute wave
trying to get source for wave
source should be 9.53.155.187
outgoing MTU = 1500
1 9.111.154.1 (9.111.154.1) 10 ms 2 ms 3 ms
2 wave (9.53.153.120) 8 ms 7 ms 5 ms
地址解析协议（ARP）登录终止后，依然重复同样的命令。注意，发送到每个网关或是目标地址的第一个信息包需要较长的回返时间。这是因为 ARP 造成的时间开销。如果在路径中有公共交换网络（WAN），第一个信息包就会因为创建连接消耗很多的内存，可能会导致超时。每个信息包缺省的超时为 3 秒。您可以通过 -w 参数项来改变其值。
第一个 10 ms 是因为在源系统（9.53.155.187）和网关 9.111.154.1 之间的 ARP 造成的。第二个 8 ms 是因为网关和最终目标（波）之间的 ARP 造成的。这种情况下，您使用 DNS，而且每次都在 traceroute 命令之前发送一个信息包，就可以搜索到 DNS 服务器。
失败的跟踪路由实例
如果距您的目标地址有很长的距离或者是网络路由很复杂，那么您或许可以通过 traceroute 命令查看出很多问题。因为很多事情都是依赖于具体实现的，所以搜索问题可能只是浪费您的时间。如果涉及到的所有路由器或子系统都在您的控制范围内，您或许可以完整的调查这个问题。
网关（路由器）问题
在下面的例子中，信息包从系统 9.53.155.187 中发出。在链接到网桥的路径上有两个路由器系统。第二个路由器系统的路由选择能力被有意去除了，把在 no 命令中的ipforwarding 参数设置为零即可。请看下面的例子：
# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
outgoing MTU = 1500
1 9.111.154.1 (9.111.154.1) 12 ms 3 ms 2 ms
2 9.111.154.1 (9.111.154.1) 3 ms !H * 6 ms !H
如果收到了 ICMP 错误信息（不包括时间超限和不能到达的端口），就会象下面一样显示：
!H
不能到达的主机
!N
不能到达的网络
!P
不能到达的协议
!S
源路由失效
!F
需要分段
目标系统的问题
如果目标系统在 3 秒的超时间隔内没有响应，所有的查询都会发生超时，结果会采用星号（*）显示。
# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
outgoing MTU = 1500
1 * * *
2 * * *
3 * * *
^C#
如果您认为这个问题是由于通信链接所造成的，可以使用 -w 标记来延长超时等待时间。可能会使用所有的查询端口，虽然这种情况很少见。您可以更改端口，然后重试。
链接到目标地址的转发单元的数目
另一个输出文件可能如下所示：
# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!
在这个例子中，12 个网关转发单元（第 13 个是终点目标）正好有一半在“等待”。然而，这些转发单元事实上并非网关。目标主机使用到达的数据报中的生存时间（ttl），作为它的 ICMP 中的应答 ttl。因而，在返回的路径中就会发生应答超时。因为 ICMP 不是为 ICMP 所发送的，所以不会接收到任何提示。在每次回返时间后的 !（惊叹号）说明存在某种类型的软件不兼容问题。（traceroute 命令发出一个有路径长度 2 倍的探测信号后就开始对原因进行诊断。目标主机事实上只是远处的七个转发单元。）
iptrace 守护程序和 ipreport、ipfilter 命令
缺省情况下，iptrace 守护程序会跟踪所有信息包。可选项 - a 允许把地址解析协议（ARP）信息包排除在外。其他的可选项可以把跟踪的范围缩小到一个指定的源主机（-s）、目标主机（-d）或是协议（-p）。因为 iptrace 守护程序可以消耗处理器非常长的时间，所以当您说明您想要跟踪的信息包时一定要尽可能的具体。
因为 iptrace 是一个守护程序，所以要在 startsrc 命令中启动 iptrace 守护程序，而不是直接从命令行启动。这种方法可以更方便进行控制和清洁关闭。典型的实例可能会如下所示：
# startsrc -s iptrace -a "-i tr0 /home/user/iptrace/log1"
这个命令启动了 iptrace 守护程序，同时建议跟踪 Token-Ring 接口（tr0）上的所有行为，并把跟踪数据放置在 /home/user/iptrace/log1 中。可以使用如下命令来终止守护程序：
# stopsrc -s iptrace
如果您没有使用 startsrc 命令来启动 iptrace 守护程序，您必须使用 ps 命令来找到它的进程标识，然后使用 kill 命令来终止它。
ipreport 命令是一个对 log 文件的格式程序。它的输出会写入到标准的输出单元。可选项允许对 RPC 信息包的识别和格式化（-r），使用数值来验证每一个信息包（-n），在每一行上都附加一个 3 个字符的串作为前缀来标识协议（-s）。下面列出的是一个典型的 ipreport 命令，它可以用来格式化一个刚刚创建的 log1 文件（所有权归根用户）：
# ipreport -ns log1 >log1_formatted
这将会生成和下面的例子相类似的一系列信息包的报告。第一个信息包是 ping 信息包的前一半。下面是最重要的字段：
* 源（SRC）和目标（DST）的主机地址，都是带小数点的十进制和 ASCII 码格式。
* IP 信息包长度（ip_len）
* 表明正在使用更高级别的协议（ip_p）
Packet Number 131
TOK: =====( packet transmitted on interface tr0 )=====Fri Jan 14 08:42:07 2000
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 0, frame control field = 40
TOK: [ src = 90:00:5a:a8:88:81, dst = 10:00:5a:4f:35:82]
TOK: routing control field = 0830, 3 routing segments
TOK: routing segments [ ef31 ce61 ba30 ]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=38892, ip_off=0
IP: ip_ttl=255, ip_sum=fe61, ip_p = 1 (ICMP)
ICMP: icmp_type=8 (ECHO_REQUEST) icmp_id=5923 icmp_seq=0
ICMP: 00000000 2d088abf 00054599 08090a0b 0c0d0e0f |-.....E.........|
ICMP: 00000010 10111213 14151617 18191a1b 1c1d1e1f |................|
ICMP: 00000020 20212223 24252627 28292a2b 2c2d2e2f | !"#$%&()*+,-./|
ICMP: 00000030 30313233 34353637 |01234567 |
下面的例子是从 ftp 操作得到的一个帧。注意，IP 信息包的大小和 LAN 的 MTU 一样大（1492 字节）。
Packet Number 501
TOK: =====( packet received on interface tr0 )=====Fri Dec 10 08:42:51 1999
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 18, frame control field = 40
TOK: [ src = 90:00:5a:4f:35:82, dst = 10:00:5a:a8:88:81]
TOK: routing control field = 08b0, 3 routing segments
TOK: routing segments [ ef31 ce61 ba30 ]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=1492, ip_id=34233, ip_off=0
IP: ip_ttl=60, ip_sum=5ac, ip_p = 6 (TCP)
TCP:
TCP: th_seq=445e4e02, th_ack=ed8aae02
TCP: th_off=5, flags
TCP: th_win=15972, th_sum=0, th_urp=0
TCP: 00000000 01df0007 2cd6c07c 00004635 000002c2 |....,..|..F5....|
TCP: 00000010 00481002 010b0001 000021b4 00000d60 |.H........!....`|
--------- Lots of uninteresting data omitted -----------
TCP: 00000590 63e40000 3860000f 4800177d 80410014 |c...8`..H..}.A..|
TCP: 000005a0 82220008 30610038 30910020 |."..0a.80.. |
ipfilter 命令从 ipreport 输出文件中释放出不同的操作报头，并在一个表中显示。同时也提供了一些自定义的有关请求的 NFS 信息和应答。
为了确定 ipfilter 命令是否已经安装而且可用，请运行下面的命令：
# lslpp -lI perfagent.tools
下面是一个命令实例：
# ipfilter log1_formatted
目前能识别的操作报头是：udp、nfs、tcp、ipx、icmp。ipfilter 命令有三种不同类型的报告，如下所示：
* 一个单独的文件（ipfilter.all），显示的是所有已选操作的列表。表中显示信息包的数量、时间、源 &、目标、长度、序列 #、Ack #、源端口、目标端口、网络接口和操作类型。
* 每个已选报头有单独的文件（ipfilter.udp、ipfilter.nfs、ipfilter.tcp、ipfilter.ipx、ipfilter.icmp）。包含的信息和 ipfilter.all 一样。
* 单个文件 nfs.rpt，有关 NFS 请求和应答的报告。表中包括：事务标识 #、请求类型、请求状态、调入信息包的数量、调入时间、调入大小、应答信息包数量、应答时间和调入与应答之间消耗的毫秒数。
适配器统计量
这一部分的命令提供的输出可以和 netstat -v 命令比较一下。它们允许您复位适配器的统计量（-r），也可以获取更详细的输出（-d），它比 netstat -v 命令的输出要详细。
entstat 命令
entstat 命令显示的是由指定以太网设备驱动收集的统计信息。除了一般的统计信息之外，用户还可以有选择地指定要显示的具体设备信息。用户可以选择性地指定除显示设备常规统计信息以外，还显示设备特定的统计信息。使用 -d 选项会列出该适配器的任何扩展统计信息，并且应该使用该选项来确保显示了所有统计信息。如果没有指定标记，就会只显示设备的通用信息。
如果运行带有 -v 标记的 netstat 命令，就会启用 entstat 命令。netstat 命令不能使用任何 entstat 命令标记。
# entstat ent0
-------------------------------------------------------------
ETHERNET STATISTICS (ent0) :
Device Type: IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
Hardware Address: 00:60:94:e9:29:18
Elapsed Time: 0 days 0 hours 0 minutes 0 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
在上面的报告中，您或许想集中在下面几点上：
发送错误
在该设备上遇到的输出错误次数。这是对那些由于硬件或网络故障导致不成功发送的计数。
接收故障
该设备上遇到的输入错误次数。这是对那些由于硬件或网络故障导致不成功接收的次数进行计数。
丢失的信息包数
设备发送驱动程序接收到信息包，但由于某些原因没有传送给设备的信息包数量。
S/W 发送队列中的信息包最大数量
在软件发送队列中排队等待的外发信息包的最大数值。
S/W 发送队列溢出值
从发送队列中溢出的外发信息包数量。
无资源错误
由于缺少资源而被硬件删除的接入信息包的数量。这种错误经常发生，因为适配器上的发送缓冲区已经用完。一些适配器可能把发送缓冲区的大小设定为可配置的参数。检查设备的配置属性（或者 SMIT 帮助），寻找可能调谐信息。
单个冲突计数 / 多路冲突计数
以太网络上的冲突次数。这些冲突在这儿说明，而不是在 netstat -i 命令输出的冲突栏中说明。
注意，在这个实例中，以太网适配器的性能很好，这是因为没有接收错误。当处于饱和状态的网络只发送不全的信息包时，有时会造成这种错误。这些不全的信息包最后都成功重发，但仍然会记录为发送错误。
如果您接收到 S/W 发送队列溢出错误，S/W 发送队列的最大信息包量会和这个适配器的发送队列限值（xmt_que_size）相对应。
注:
如果适配器不支持软件发送队列，这些值可以代表硬件队列。如果出现发送队列溢出，那么就增加驱动的硬件或软件的队列限值。
如果没有足够的接收资源，那么可能显示的是信息包丢失：，而且根据适配器的类型不同，可能显示的是超出 Rcv 缓冲区或是无资源错误：或者一些类似的计数器。
消耗的时间显示的是从上次复位统计量之后所用的实时时间段。要对统计量进行复位，可以使用 entstat -r adapter_name 命令。
对于 Token-Ring、FDDI 和 ATM 接口，使用 tokstat、fddistat 和 atmstat 命令可以显示类似的输出。
tokstat 命令
tokstat 命令显示的是由指定的 Token-Ring 设备驱动所收集的统计量。除了设备驱动信息外，用户还可以有选择地指定要显示的特定设备信息。如果没有指定任何标记，只会显示设备驱动信息。
使用 netstat 命令和 -v 标记同样可以启用这个命令。netstat 命令不能带有 tokstat 命令的任何标记。
tokstat tok0 命令的生成的输出和问题的确定和 entstat 命令中提到的类似。
fddistat 命令
fddistat 命令显示的是由指定的 FDDI 设备驱动所收集的统计量信息。除了设备驱动信息外，用户还可以有选择地指定要显示的特定设备信息。如果没有指定任何标记，只会显示设备驱动信息。
同样可以使用 netstat 命令和 -v 标记来启用这个命令。netstat 命令不能带有 fddistat 命令的任何标记。
fddistat fddi0 命令生成的输出和问题的确定和 entstat 命令中提到的是类似的。
atmstat 命令
atmstat 命令显示的是由指定的 ATM 设备驱动所收集的统计量信息。除了设备驱动信息外，用户还可以有选择地指定要显示的特定设备信息。如果没有指定任何标记，只会显示设备驱动信息。
atmstat atm0 命令的输出和问题的确定和在 entstat 命令中提到的类似。
no 命令
使用 no 命令可以显示当前的网络变量值，也可变更选项。
-a
打印所有可选项和当前值（比如：no -a）
-d
把选项恢复为缺省状态（比如：no -dthewall ）
-o
选项=新值（比如：no -othewall=16384）
如果需要 no 命令所有属性的列表，请参阅『网络选项可调参数』。
一些网络属性是运行属性，可以随时修改。其余的是加载属性，必须在加载 netinet 内核扩展程序之前设置。
注:
如果您的系统使用的是 Berkeley 风格的网络配置，就把这些属性设定在靠近 /etc/rc.bsdnet 文件的顶端。如果您使用的是 SP 系统，就需要编辑 tuning.cust 文件，具体说明在 RS/6000 SP：安装和再定位手册中。
注:
no 命令执行的检查是无范围的。如果使用不正确，no 命令可以导致您的系统不能操作。
