【導讀】出現性能問題的時候，您的系統可能一點過失也沒有，而真正的故障原因卻是外面的建築物。如果要知道是否是網絡影響總體的性能，一個簡單的方法就是比較涉及網絡的操作和那些和網絡無關的操作。
如果您正在運行的程序在進行相當距離的遠程讀取和寫入，而且運行很慢，但其他的操作看起來運行正常，這時可能是網絡問題造成的。如果您正在運行的程序在進行相當距離的遠程讀取和寫入，而且運行很慢，但其他的操作看起來運行正常，這時可能是網絡問題造成的。一些潛在的網絡瓶頸可能由以下因素造成：
* 客戶端網絡接口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 命令可以導致您的系統不能操作。
