AIX系統網路效能分析(轉)
AIX系統網路效能分析(轉)[@more@]【導讀】出現效能問題的時候，您的系統可能一點過失也沒有，而真正的故障原因卻是外面的建築物。如果要知道是否是網路影響總體的效能，一個簡單的方法就是比較涉及網路的操作和那些和網路無關的操作。
如果您正在執行的程式在進行相當距離的遠端讀取和寫入，而且執行很慢，但其他的操作看起來執行正常，這時可能是網路問題造成的。如果您正在執行的程式在進行相當距離的遠端讀取和寫入，而且執行很慢，但其他的操作看起來執行正常，這時可能是網路問題造成的。一些潛在的網路瓶頸可能由以下因素造成：
* 客戶端網路介面s
* 網路頻寬
* 網路拓撲結構
* 伺服器端網路介面
* 伺服器端 CPU 負載
* 伺服器儲存器使用狀況
* 伺服器頻寬
* 配置效率低下
一些工具能夠進行網路資料統計，給出各種各樣的資訊，但只有其中的一部分是和效能調諧相關的。
為了改善效能，您可以使用 no （網路選項）命令和 nfso 命令來對 NFS 選項進行調諧。您還可以使用 chdev 和 ifconfig 命令來改變系統和網路的引數值。
ping 命令
在下面這些情況下 ping 命令是有幫助的：
* 確定網路的狀態和各種外部主機。
* 跟蹤並隔離硬體和軟體故障。
* 對網路的檢測、測定和管理。
下面列出的是一些和效能調諧相關聯的 ping 命令引數項：
-c
指定了資訊包數。如果您有 IP 跟蹤記錄，這個引數項是有用的。您可以捕捉到 ping 資訊包的最小值。
-s
指定資訊包的長度。您可以使用這個引數項來檢查分段和重新組合。
-f
以 10 ms 的間歇傳送資訊包或是在每次回應之後立即傳送。只有根使用者才可以使用這個引數項。
如果您需要載入您的網路或系統，使用 -f 引數項就很方便。比如，如果您猜測您的故障是過量負載造成的，可以試著有意載入您的工作區來證實您的懷疑。開啟一些 aixterm 視窗，並在每個視窗中執行 ping -f 命令。您的乙太網使用狀況很快就會達到接近 100%。下面是一個例子：
# date ; ping -c 1000 -f wave ; date
Fri Jul 23 11:52:39 CDT 1999
PING wave.austin.ibm.com: (9.53.153.120): 56 data bytes
.
----wave.austin.ibm.com PING Statistics----
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max = 1/1/23 ms
Fri Jul 23 11:52:42 CDT 1999
注:
這個命令在網路上執行可能很困難，要小心使用。連續地執行 ping 命令只能由根使用者來操作。
在這個例子中，1000 個資訊包傳送了 3 秒。要知道這個命令使用了 IP 和網路控制資訊協議（ICMP），因而沒有涉及到任何傳輸協議（UDP/TCP）和應用程式。測到的資料，比如往返的時間，不會影響到總體的效能特徵。
如果您試圖傳送大量的資訊包到您的目的地址，就要考慮如下幾點：
* 傳送資訊包對您的系統來說，增加了負載。
* 使用 netstat -i 命令可以在試驗過程中監測您的網路介面的狀態。透過檢視 Oerrs 的輸出您可以發現系統在傳送中在刪除資訊包。
* 您也應該監控其他資源，比如 mbuf 和傳送 / 接收佇列。很難在目標系統上增加一個大的負載。或許在其他系統過載之前您的系統就過載了。
* 考慮結果的相關性。如果您想監控或測試的僅是一個目標系統，就在其他的一些系統上做同樣的試驗來進行比較，因為或許您的網路或是路由器出現了故障。
ftp 命令
您可以使用 ftp 命令來傳送一個非常大的檔案，使用 /dev/zero 作為輸入，/dev/null 作為輸出。這樣您就可以傳輸一個大檔案，而不用考慮磁碟（可能是瓶頸問題），也不需要在記憶體中快取記憶體整個檔案。
使用下面的 ftp 子命令（改變 count 的值可以增加或是減少塊的數量，塊的數量可以透過 dd 命令讀出）：
> bin
> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
記住，如果您改變了 TCP 的傳送或接收空間引數，對於 ftp 命令，您必須重新整理 inetd 守護程式，使用 refresh -s inetd 命令就可以重新整理。
要確保 tcp_senspace 和 tcp_recvspace 的值至少為 65535 （對於 Gigabit 乙太網 "jumbo frames"和帶有 MTU 9180 的 ATM 來說），如果要獲得更好的效能就需要更大的值，這是因為 MTU 的值也增加了。
下面舉的是一個設定引數的例子：
# no -o tcp_sendspace=65535
# no -o tcp_recvspace=65535
# refresh -s inetd
# refresh -s inetd
0513-095 重新整理子系統的請求成功完成。
下面列出的是 ftp 子命令：
ftp> bin
200 Type set to I.
ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
10000+0 records in
10000+0 records out
226 Transfer complete.
327680000 bytes sent in 8.932 seconds (3.583e+04 Kbytes/s)
local: |dd if=/dev/zero bs=32k count=10000 remote: /dev/null
ftp> quit
221 Goodbye.
網路統計命令
netstat 命令可以用來顯示網路的狀態。按慣例來看，它是用來做故障識別而不是作為效能評定用的。然而，netstat 命令可以用來確定網路上的流量，從而可以確定效能故障是否是由於網路阻塞所引起。
netstat 命令顯示的是關於在配置的網路介面上的流量，如下面所示：
* 和套接字有關的任何一個協議控制塊的地址及所有套接字的狀態
* 收到、傳送出去和在通訊子系統中丟失的資訊包數量
* 每個介面的累計統計資訊
* 路由和它們的狀態
使用 netstat 命令
netstat 命令顯示的是有效連線的各種網路相關的資料結構內容。本章中只討論和網路效能決定性相關的引數項和輸出域。對於其他所有的引數項和欄目，請參閱《AIX 5L V5.2 命令參考大全》。
netstat -i
顯示的是所有配置介面的狀態。
下面的例子顯示的是一個帶有整合乙太網和 Token-Ring 介面卡的工作站的統計資訊：
# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 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
顯示 mbuf 儲存器管理程式所記錄的統計資訊。在 netstat -m 命令的輸出中最有用的統計資訊就是顯示被拒絕的 mbuf 請求的計數器和故障 一列中的非零值。如果沒有顯示被拒絕的 mbuf 請求，那麼可以肯定 SMP 系統在執行 4.3.2 版本或是更晚版本的作業系統，為了效能方面的原因，預設設定為關閉全域性的統計資訊。要啟用全域性的統計資訊，需要把 no 引數 extended_netstats 設定為 1。需要更改 /etc/rc.net 檔案然後重啟系統，就可以實現設定。
下面的例子顯示的是 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 -
kresna.id.ibm.co itsorusi UGHW 0 14 1492 tr0 -
9.184.104.111 kresna.id.ibm.com UGc 0 5 - 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
traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
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 守護程式結合使用 ipreport 命令，可以獲取一個 LAN 組織結構的詳細而且有連續資訊包的記述，這個是由工作負載所生成的。要使用帶有作業系統版本 4 的 iptrace 守護程式，您需要 bos.net.tcp.server 檔案集。iptrace 守護程式就包括在這個檔案集中，和其他有用的命令一樣，比如 trpt 和 tcdump 命令。iptrace 守護程式只能由根使用者啟動。
預設情況下，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: < SRC = 129.35.145.140 > (alborz.austin.ibm.com)
IP: < DST = 129.35.145.135 > (xactive.austin.ibm.com)
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: < SRC = 129.35.145.135 > (xactive.austin.ibm.com)
IP: < DST = 129.35.145.140 > (alborz.austin.ibm.com)
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 核心擴充套件程式之前設定。
注:
當使用 no 命令來改變引數時，更改只有在下次系統啟動之後才會生效。這時，所有的引數都被初始設定為它們的預設值。如果想做永久更改，把合適的 no 命令加入到 /etc/rc.net 檔案中就可以。
如果您的系統使用的是 Berkeley 風格的網路配置，就把這些屬性設定在靠近 /etc/rc.bsdnet 檔案的頂端。如果您使用的是 SP 系統，就需要編輯 tuning.cust 檔案，具體說明在 RS/6000 SP：安裝和再定位手冊中。
注:
no 命令執行的檢查是無範圍的。如果使用不正確，no 命令可以導致您的系統不能操作。
如果您正在執行的程式在進行相當距離的遠端讀取和寫入，而且執行很慢，但其他的操作看起來執行正常，這時可能是網路問題造成的。如果您正在執行的程式在進行相當距離的遠端讀取和寫入，而且執行很慢，但其他的操作看起來執行正常，這時可能是網路問題造成的。一些潛在的網路瓶頸可能由以下因素造成：
* 客戶端網路介面s
* 網路頻寬
* 網路拓撲結構
* 伺服器端網路介面
* 伺服器端 CPU 負載
* 伺服器儲存器使用狀況
* 伺服器頻寬
* 配置效率低下
一些工具能夠進行網路資料統計，給出各種各樣的資訊，但只有其中的一部分是和效能調諧相關的。
為了改善效能，您可以使用 no （網路選項）命令和 nfso 命令來對 NFS 選項進行調諧。您還可以使用 chdev 和 ifconfig 命令來改變系統和網路的引數值。
ping 命令
在下面這些情況下 ping 命令是有幫助的：
* 確定網路的狀態和各種外部主機。
* 跟蹤並隔離硬體和軟體故障。
* 對網路的檢測、測定和管理。
下面列出的是一些和效能調諧相關聯的 ping 命令引數項：
-c
指定了資訊包數。如果您有 IP 跟蹤記錄，這個引數項是有用的。您可以捕捉到 ping 資訊包的最小值。
-s
指定資訊包的長度。您可以使用這個引數項來檢查分段和重新組合。
-f
以 10 ms 的間歇傳送資訊包或是在每次回應之後立即傳送。只有根使用者才可以使用這個引數項。
如果您需要載入您的網路或系統，使用 -f 引數項就很方便。比如，如果您猜測您的故障是過量負載造成的，可以試著有意載入您的工作區來證實您的懷疑。開啟一些 aixterm 視窗，並在每個視窗中執行 ping -f 命令。您的乙太網使用狀況很快就會達到接近 100%。下面是一個例子：
# date ; ping -c 1000 -f wave ; date
Fri Jul 23 11:52:39 CDT 1999
PING wave.austin.ibm.com: (9.53.153.120): 56 data bytes
.
----wave.austin.ibm.com PING Statistics----
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max = 1/1/23 ms
Fri Jul 23 11:52:42 CDT 1999
注:
這個命令在網路上執行可能很困難，要小心使用。連續地執行 ping 命令只能由根使用者來操作。
在這個例子中，1000 個資訊包傳送了 3 秒。要知道這個命令使用了 IP 和網路控制資訊協議（ICMP），因而沒有涉及到任何傳輸協議（UDP/TCP）和應用程式。測到的資料，比如往返的時間，不會影響到總體的效能特徵。
如果您試圖傳送大量的資訊包到您的目的地址，就要考慮如下幾點：
* 傳送資訊包對您的系統來說，增加了負載。
* 使用 netstat -i 命令可以在試驗過程中監測您的網路介面的狀態。透過檢視 Oerrs 的輸出您可以發現系統在傳送中在刪除資訊包。
* 您也應該監控其他資源，比如 mbuf 和傳送 / 接收佇列。很難在目標系統上增加一個大的負載。或許在其他系統過載之前您的系統就過載了。
* 考慮結果的相關性。如果您想監控或測試的僅是一個目標系統，就在其他的一些系統上做同樣的試驗來進行比較，因為或許您的網路或是路由器出現了故障。
ftp 命令
您可以使用 ftp 命令來傳送一個非常大的檔案，使用 /dev/zero 作為輸入，/dev/null 作為輸出。這樣您就可以傳輸一個大檔案，而不用考慮磁碟（可能是瓶頸問題），也不需要在記憶體中快取記憶體整個檔案。
使用下面的 ftp 子命令（改變 count 的值可以增加或是減少塊的數量，塊的數量可以透過 dd 命令讀出）：
> bin
> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
記住，如果您改變了 TCP 的傳送或接收空間引數，對於 ftp 命令，您必須重新整理 inetd 守護程式，使用 refresh -s inetd 命令就可以重新整理。
要確保 tcp_senspace 和 tcp_recvspace 的值至少為 65535 （對於 Gigabit 乙太網 "jumbo frames"和帶有 MTU 9180 的 ATM 來說），如果要獲得更好的效能就需要更大的值，這是因為 MTU 的值也增加了。
下面舉的是一個設定引數的例子：
# no -o tcp_sendspace=65535
# no -o tcp_recvspace=65535
# refresh -s inetd
# refresh -s inetd
0513-095 重新整理子系統的請求成功完成。
下面列出的是 ftp 子命令：
ftp> bin
200 Type set to I.
ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
10000+0 records in
10000+0 records out
226 Transfer complete.
327680000 bytes sent in 8.932 seconds (3.583e+04 Kbytes/s)
local: |dd if=/dev/zero bs=32k count=10000 remote: /dev/null
ftp> quit
221 Goodbye.
網路統計命令
netstat 命令可以用來顯示網路的狀態。按慣例來看，它是用來做故障識別而不是作為效能評定用的。然而，netstat 命令可以用來確定網路上的流量，從而可以確定效能故障是否是由於網路阻塞所引起。
netstat 命令顯示的是關於在配置的網路介面上的流量，如下面所示：
* 和套接字有關的任何一個協議控制塊的地址及所有套接字的狀態
* 收到、傳送出去和在通訊子系統中丟失的資訊包數量
* 每個介面的累計統計資訊
* 路由和它們的狀態
使用 netstat 命令
netstat 命令顯示的是有效連線的各種網路相關的資料結構內容。本章中只討論和網路效能決定性相關的引數項和輸出域。對於其他所有的引數項和欄目，請參閱《AIX 5L V5.2 命令參考大全》。
netstat -i
顯示的是所有配置介面的狀態。
下面的例子顯示的是一個帶有整合乙太網和 Token-Ring 介面卡的工作站的統計資訊：
# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 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
顯示 mbuf 儲存器管理程式所記錄的統計資訊。在 netstat -m 命令的輸出中最有用的統計資訊就是顯示被拒絕的 mbuf 請求的計數器和故障 一列中的非零值。如果沒有顯示被拒絕的 mbuf 請求，那麼可以肯定 SMP 系統在執行 4.3.2 版本或是更晚版本的作業系統，為了效能方面的原因，預設設定為關閉全域性的統計資訊。要啟用全域性的統計資訊，需要把 no 引數 extended_netstats 設定為 1。需要更改 /etc/rc.net 檔案然後重啟系統，就可以實現設定。
下面的例子顯示的是 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 -
kresna.id.ibm.co itsorusi UGHW 0 14 1492 tr0 -
9.184.104.111 kresna.id.ibm.com UGc 0 5 - 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
traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
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
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
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 守護程式結合使用 ipreport 命令，可以獲取一個 LAN 組織結構的詳細而且有連續資訊包的記述，這個是由工作負載所生成的。要使用帶有作業系統版本 4 的 iptrace 守護程式，您需要 bos.net.tcp.server 檔案集。iptrace 守護程式就包括在這個檔案集中，和其他有用的命令一樣，比如 trpt 和 tcdump 命令。iptrace 守護程式只能由根使用者啟動。
預設情況下，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: < SRC = 129.35.145.140 > (alborz.austin.ibm.com)
IP: < DST = 129.35.145.135 > (xactive.austin.ibm.com)
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: < SRC = 129.35.145.135 > (xactive.austin.ibm.com)
IP: < DST = 129.35.145.140 > (alborz.austin.ibm.com)
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 核心擴充套件程式之前設定。
注:
當使用 no 命令來改變引數時，更改只有在下次系統啟動之後才會生效。這時，所有的引數都被初始設定為它們的預設值。如果想做永久更改，把合適的 no 命令加入到 /etc/rc.net 檔案中就可以。
如果您的系統使用的是 Berkeley 風格的網路配置，就把這些屬性設定在靠近 /etc/rc.bsdnet 檔案的頂端。如果您使用的是 SP 系統，就需要編輯 tuning.cust 檔案，具體說明在 RS/6000 SP：安裝和再定位手冊中。
注:
no 命令執行的檢查是無範圍的。如果使用不正確，no 命令可以導致您的系統不能操作。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10617731/viewspace-948079/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- AIX作業系統效能分析報告AI作業系統
- AIX 下磁碟 I/O 效能分析[轉]AI
- AIX使用非同步I/O(aio)提高系統效能(轉)AI非同步
- 提高Linux系統效能加速網路應用程式(轉)Linux
- AIX 系統標識(轉)AI
- AIX系統日常管理(轉)AI
- 【AIX】AIX 下磁碟 I/O 效能分析AI
- AIX系統磁碟I/O效能評估AI
- 系統分析員之路----系統分析員基本功 【網路】
- AIX 系統引數配置 -- 轉AI
- 轉-AIX檔案系統滿AI
- 使用NIM Server網路半自動安裝AIX系統ServerAI
- AIX 網路AI
- 快速透視 AIX 系統 （轉載）AI
- AIX系統級命令簡介(轉)AI
- linux / aix 效能分析工具nmonLinuxAI
- Linux日誌檔案系統及效能分析(轉)Linux
- Linux系統網路詳解(轉)Linux
- AIX檔案系統滿的問題分析AI
- Linux效能分析之網路篇Linux
- AIX 作業系統調優 效能指標祥解AI作業系統指標
- 用nmon監控aix | linux的效能，nmon_analyser分析系統監控資料AILinux
- JMeter—系統效能分析思路(十三)JMeter
- Linux系統效能調優之效能分析Linux
- NIS網路資訊系統簡介(轉)
- FreeBSD網路檔案系統（NFS）(轉)NFS
- 網路系統安全綜合解決方案 (轉)
- Windows系統網路工具使用手冊 (轉)Windows
- AIX作業系統的shell簡介(轉)AI作業系統
- AIX作業系統shell的引數(轉)AI作業系統
- aix系統vgAI
- linux系統效能調優第一步——效能分析(vmstat) (轉載)Linux
- 【轉】 AIX系統中可否動態縮小檔案系統大小AI
- [zt] Linux及AIX 效能分析工具 - nmonLinuxAI
- 全網的網路管理系統只管裝置嗎(轉)
- UNIX(IBM AIX)系統基礎知識(轉)IBMAI
- 【AIX 學習】網路管理AI
- 容器網路流量轉發分析