AIX网络性能分析.doc

出现性能问题的时候，您的系统可能一点过失也没有，而真正的故障原因却是外面的建筑物。如果要知道是否是网络影响总体的性能，一个简单的方法就是比较涉及网络的操作和那些和网络无关的操作。如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。如果您正在运行的程序在进行相当距离的远程读取和写入，而且运行很慢，但其他的操作看起来运行正常，这时可能是网络问题造成的。一些潜在的网络瓶颈可能由以下因素造成： * 客户端网络接口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 ; dateFri Jul 23 11:52:39 CDT 1999PING : (20): 56 data PING Statistics-1000 packets transmitted, 1000 packets received, 0% packet lossround-trip min/avg/max = 1/1/23 msFri 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 inetd0513-095 刷新子系统的请求成功完成。下面列出的是 ftp 子命令：ftp bin200 Type set to I.ftp put |dd if=/dev/zero bs=32k count=10000 /dev/null200 PORT command successful.150 Opening data connection for /dev/null.10000+0 records in10000+0 records out226 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/nullftp quit221 Goodbye.网络统计命令netstat 命令可以用来显示网络的状态。按惯例来看，它是用来做故障识别而不是作为性能评定用的。然而，netstat 命令可以用来确定网络上的流量，从而可以确定性能故障是否是由于网络阻塞所引起。netstat 命令显示的是关于在配置的网络接口上的流量，如下面所示： * 和套接字有关的任何一个协议控制块的地址及所有套接字的状态 * 收到、发送出去和在通信子系统中丢失的信息包数量 * 每个接口的累计统计信息 * 路由和它们的状态使用 netstat 命令netstat 命令显示的是有效连接的各种网络相关的数据结构内容。本章中只讨论和网络性能决定性相关的参数项和输出域。对于其他所有的参数项和栏目，请参阅AIX 5L V5.2 命令参考大全。netstat -i显示的是所有配置接口的状态。下面的例子显示的是一个带有集成以太网和 Token-Ring 适配器的工作站的统计信息：# netstat -iName Mtu Network Address Ipkts Ierrs Opkts Oerrs Colllo0 16896 144834 0 144946 0 0lo0 16896 127 localhost 144834 0 144946 0 0tr0 1492 10.0.5a.4f.3f.61 658339 0 247355 0 0tr0 1492 9.3.1 ah6000d 658339 0 247355 0 0en0 1500 8.0.5a.d.a2.d5 0 0 112 0 0en0 1500 1.2.3 0 0 112 0 0count 的值从系统启动开始进行汇总。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 -Znetstat 命令对所有 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 -m29 mbufs in use:16 mbuf cluster pages in use71 Kbytes allocated to mbufs0 requests for mbufs denied0 calls to protocol drain routines内核分配统计信息：* CPU 0 *By size inuse calls failed delayed free hiwat freed32 419 544702 0 0 221 800 064 173 22424 0 0 19 400 0128 121 37130 0 0 135 200 4256 1201 118326233 0 0 239 480 138512 330 671524 0 0 14 50 541024 74 929806 0 0 82 125 22048 384 1820884 0 0 8 125 56054096 516 1158445 0 0 46 150 218192 9 5634 0 0 1 12 2716384 1 2953 0 0 24 30 4132768 1 1 0 0 0 1023 0By type inuse calls failed delayed memuse memmax mapbStreams mblk statistic failures:0 high priority mblk failures0 medium priority mblk failures0 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 -vnetstat -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:18Elapsed Time: 9 days 19 hours 5 minutes 51 secondsTransmit Statistics: Receive Statistics:- -Packets: 0 Packets: 0Bytes: 0 Bytes: 0Interrupts: 0 Interrupts: 0Transmit Errors: 0 Receive Errors: 0Packets Dropped: 0 Packets Dropped: 0 Bad Packets: 0Max Packets on S/W Transmit Queue: 0S/W Transmit Queue Overflow: 0Current S/W+H/W Transmit Queue Length: 0Broadcast Packets: 0 Broadcast Packets: 0Multicast Packets: 0 Multicast Packets: 0No Carrier Sense: 0 CRC Errors: 0DMA Underrun: 0 DMA Overrun: 0Lost CTS Errors: 0 Alignment Errors: 0Max Collision Errors: 0 No Resource Errors: 0Late Collision Errors: 0 Receive Collision Errors: 0Deferred: 0 Packet Too Short Errors: 0SQE Test: 0 Packet Too Long Errors: 0Timeout Errors: 0 Packets Discarded by Adapter: 0Single Collision Count: 0 Receiver Start Count: 0Multiple Collision Count: 0Current HW Transmit Queue Length: 0General Statistics:-No mbuf Errors: 0Adapter Reset Count: 0Driver Flags: Up Broadcast Running Simplex 64BitSupport PrivateSegmentIBM 10/100 Mbps Ethernet PCI Adapter Specific Statistics:-Chip Version: 25RJ45 Port Link Status : downMedia Speed Selected: 10 Mbps Half DuplexMedia Speed Running: UnknownReceive Pool Buffer Size: 384Free Receive Pool Buffers: 128No Receive Pool Buffer Errors: 0Inter Packet Gap: 96Adapter Restarts due to IOCTL commands: 0Packets 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: 0Excessive deferral errors: 0x0-TOKEN-RING STATISTICS (tok0) :Device Type: IBM PCI Tokenring Adapter (14103e00)Hardware Address: 00:20:35:7a:12:8aElapsed Time: 29 days 18 hours 3 minutes 47 secondsTransmit Statistics: Receive Statistics:- -Packets: 1355364 Packets: 55782254Bytes: 791555422 Bytes: 6679991641Interrupts: 902315 Interrupts: 55782192Transmit Errors: 0 Receive Errors: 1Packets Dropped: 0 Packets Dropped: 0 Bad Packets: 0Max Packets on S/W Transmit Queue: 182S/W Transmit Queue Overflow: 42Current S/W+H/W Transmit Queue Length: 0Broadcast Packets: 18878 Broadcast Packets: 54615793Multicast Packets: 0 Multicast Packets: 569Timeout Errors: 0 Receive Congestion Errors: 0Current SW Transmit Queue Length: 0Current HW Transmit Queue Length: 0General Statistics:-No mbuf Errors: 0 Lobe Wire Faults: 0Abort Errors: 12 AC Errors: 0Burst Errors: 1 Frame Copy Errors: 0Frequency Errors: 0 Hard Errors: 0Internal Errors: 0 Line Errors: 0Lost Frame Errors: 0 Only Station: 1Token Errors: 0 Remove Received: 0Ring Recovered: 17 Signal Loss Errors: 0Soft Errors: 35 Transmit Beacon Errors: 0Driver Flags: Up Broadcast Running AlternateAddress 64BitSupport ReceiveFunctionalAddr 16 MbpsIBM PCI Tokenring Adapter (14103e00) Specific Statistics:-Media Speed Running: 16 Mbps Half DuplexMedia Speed Selected: 16 Mbps Full DuplexReceive Overruns : 0Transmit Underruns : 0ARI/FCI errors : 0Microcode level on the adapter :001PX11B2Num pkts in priority sw tx queue : 0Num pkts in priority hw tx queue : 0Open 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.1netstat -p protocol显示由协议参量（udp、tcp、ip、icmp）所指定值的统计信息，要么是一个协议所熟悉的名称要么是它的一个代名。在 /etc/protocols 文件中列出了一些协议名称和它们的代名。一个空响应表明，没有要报告的数据。如果没有统计程序，那么协议参量指定值的程序报告就是不可知的。下面的例子显示的是 ip 协议的输出：# netstat -p ipip: 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 udpudp: 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 数据报是广播数据报，就不会产生 IC