【正文】 下面列出的是缺省值。 trcstop如果有 O 參數(shù)項，您就可以指定要生成的報告類型。 netpmon o O all。下面的 netpmon 命令是在一臺 NFS 服務器上運行，它執(zhí)行 sleep 命令并在 400 秒后創(chuàng)建一個報告。讀取全部文件之后，在標準輸出單元上會顯示網(wǎng)絡操作的通報（在本例中是導出到 pg 命令）。trcrpt r 命令必須在跟蹤記錄文件上執(zhí)行，并導向另一個文件，如下所示： gennames trcrpt r 這時，一個調(diào)整過的跟蹤記錄文件送進 netpmon 命令來通報由上一個被記錄的跟蹤進程所捕捉到的 I/O 端口動作，如下所示： netpmon i n | pg在這個示例中，netpmon 命令從輸入文件 中讀取文件系統(tǒng)跟蹤事件。這種情況下，netpmon 的報告就以文件的形式對系統(tǒng)這個時段的網(wǎng)絡操作進行了概括。它可以在客戶和服務器端運行。那時可以生成所有的指定報告，而且會退出 netpmon 命令。netpmon 的使用netpmon 命令可以立即啟動跟蹤（除非使用了 d 可選項）。為了確定 netpmon 命令是否已安裝而且可用，可以運行如下命令： lslpp lI 使用 netpmon 命令可以啟動跟蹤過程，可選用 trcoff 子命令進行暫掛，選用 trcon 子命令繼續(xù)進行，終止跟蹤采用 trcstop 子命令。 * 和 NFS 讀取寫入系統(tǒng)調(diào)用相關聯(lián)的響應時間和大小。下面列出的是要計算的量： * 在設備驅(qū)動級別上和發(fā)送 / 接收操作相關聯(lián)的響應時間和大小。 * NFS I/O 端口 o 客戶端：RPC 請求、NFS 讀取 / 寫入請求。 * 網(wǎng)絡套接字調(diào)用 o 監(jiān)控網(wǎng)絡套接字上的 send()、recv()、sendto()、recvfrom()、sendmsg()、read() 和 write() 子程序。 o 在 I/O 端口傳輸?shù)那闆r下，命令監(jiān)控使用狀況、隊列長度和目標主機。在它的通常模式下，netpmon 命令一般在運行監(jiān)控一個或多個應用程序或是系統(tǒng)命令時運行。因為它使用了跟蹤工具，所以 netpmon 只能由根用戶或是系統(tǒng)工作組的某個成員運行。因而，各自的計數(shù)器都有對 N/A 的字段值，而且累計計數(shù)存放在 NFS/RPC 總和字段中。對于 NFS/RPC 部分而言，經(jīng)由 RPC 的進入信息包和經(jīng)由 NFS 的信息包是一樣的，這樣這些數(shù)量就不會被加入到 NFS/RPC 總和字段中去，因而是 N/A。要查看協(xié)議層的詳細內(nèi)容，請參閱netstat s 命令的輸出。這時 netstat v 命令可以用來幫助確定統(tǒng)計的是哪一種錯誤。適配器錯誤有各種各樣的原因，使用 netstat v 命令可以查看更多的細節(jié)內(nèi)容。下面是一個例子，使用 netstat r f inet 命令來顯示路由表： netstat r f inetRouting tablesDestination Gateway Flags Refs Use PMTU If Exp GroupsRoute Tree for Protocol Family 2:default itsorusi UGc 1 348 tr0 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 itsorusi UGHW 1 45 1492 tr0 itsorusi UGHW 0 14 1492 tr0 UGc 0 5 tr0 127 localhost U 3 96 lo0 netstat D您可以使用 D 參數(shù)項來查看在通信子系統(tǒng)每一層中刪除信息包的同時，每一層進入和導出的信息包。這個大小稱為是路徑 MTU。對于兩個通過多重網(wǎng)絡路徑通信的主機來說，如果發(fā)送的信息包比路徑重任何一個網(wǎng)路的最小 MTU 值要大，就會對這個信息包進行分段。它把 netstat s 命令的所有統(tǒng)計計數(shù)器都進行清零。netstat s s沒有正式加以說明的 s s 參數(shù)項顯示的只是 netstat s 命令輸出中不是零的那些行，這樣就可以更容易找到錯誤的統(tǒng)計。這些持續(xù)的重發(fā)操作使得 CPU 的利用率更高，而且如果接收節(jié)點沒有收到信息包，它最終會被刪除掉。然后它會重新發(fā)送信息包。復制信息包會增加網(wǎng)絡流量。當接收節(jié)點最終接收到所有重發(fā)的信息包時會進行復制。同樣，需要比較接收到的信息包量和完整復制的信息包量。如果重發(fā)的信息包數(shù)大于總發(fā)送信息包量的 1015%，TCP 就會出現(xiàn)超時，這表明網(wǎng)絡流量負載很大，在超時之前不能返回應答信號（ACK）。如果系統(tǒng)處于飽和狀態(tài)，那么您必須降低它的負載或是增加資源。如果 netstat p udp 命令表示套接字溢出，那么您或許需要增加服務器端 nfsd 守護程序的數(shù)量。如果這個值較高，就需要檢查應用程序如何如何處理套接字的。因而，肯定會發(fā)送 ICMP 目標地址無法到達 端口無法到達的信息。下面的例子顯示的是 udp 協(xié)議的輸出： netstat p udpudp: 11521194 datagrams received 0 inplete 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下面是重要的統(tǒng)計量： * 無效校驗和 無效校驗和可能是由于硬件板卡或是電纜故障造成的。然而，如果您知道應用程序正在發(fā)送大量的數(shù)據(jù)，同時仍然出現(xiàn)分段，就需要確定它的起因。比如，一個發(fā)送小數(shù)量數(shù)據(jù)的應用程序就能夠?qū)е鲁霈F(xiàn)分段。分段會導致 CPU 的額外負載，所以確定它的起因很重要。網(wǎng)絡路徑中的網(wǎng)關或路由器可能也有比網(wǎng)絡中其他節(jié)點小得多的 MTU 值。對于小的 MTU 網(wǎng)絡有一個準則，如果有 10% 或者更多的信息包進行了分段，那么您就應該進一步調(diào)查以確定其原因。 * 創(chuàng)建的段 發(fā)送 IP 數(shù)據(jù)報時系統(tǒng)中創(chuàng)建的段的數(shù)目。 * 從該主機發(fā)送的信息包 由這個系統(tǒng)創(chuàng)建并發(fā)送出去的 IP 數(shù)據(jù)報數(shù)目。為了避免這種情況，可以使用 no 命令來提高 ipfragttl 的網(wǎng)絡參數(shù)值。 * 收到的段 收到的段總數(shù)。t be fragmented 0 IP Multicast packets dropped due to no receiver 0 ipintrq overflows下面要提到的是高亮顯示的部分： * 接收到的信息包總量 接收到的 IP 數(shù)據(jù)報總數(shù)。如果沒有統(tǒng)計程序，那么協(xié)議參量指定值的程序報告就是不可知的。在 /etc/protocols 文件中列出了一些協(xié)議名稱和它們的代名。附加的準則： * 為了檢查過載的以太網(wǎng)絡，要做一些計算（從 netstat v 命令中）：（最大沖突錯誤 + 超時錯誤）/ 發(fā)送信息包量 如果結(jié)果大于 5%，就需要重新改組網(wǎng)絡來平衡負載。比較使用 netstat m 命令和 netstat v 命令（以太網(wǎng)和 TokenRing 部分）的值?？梢允褂?netstat m 命令來進行驗證，增加 thewall 的參數(shù)值。這通常發(fā)生在接收操作中，驅(qū)動程序必須內(nèi)存緩沖區(qū)來處理入站信息包的情況下。 * 接收沖突錯誤 在接收過程中有沖突錯誤的接入信息包的數(shù)量。 * 單獨沖突計數(shù) 在發(fā)送過程中有單獨沖突的外發(fā)信息包數(shù)量。 * 最近的沖突錯誤 由于上次沖突錯誤造成的不成功發(fā)送的數(shù)量。 * 最大沖突錯誤 由于過多沖突導致的不成功發(fā)送的次數(shù)。標準情況下，總線上較低插槽號的適配器由于擁有較高的總線優(yōu)先權，使用的總線量很大，以至于在較高插槽號的適配器不能接收到服務。當 MCA 總線對于適配器來說過于繁忙，不能夠?qū)π畔褂?DMA 時會出現(xiàn)這種情況。 * DMA 超限 當適配器使用 DMA 把信息包放入系統(tǒng)內(nèi)存而且傳輸過程沒有終止時， DMA 超限統(tǒng)計信息會進行增一操作。如果其值較高，可能暗示著網(wǎng)絡的負載較重，在使用多點傳送。 如果廣播信息包的值較高，就把它和接收信息包的總數(shù)相比較。必須增加發(fā)送隊列的大小。 * S/W 發(fā)送隊列溢出 外發(fā)信息包的數(shù)量從軟件發(fā)送隊列中溢出。因為隊列是和設備驅(qū)動程序及接口的適配器相關聯(lián)的，所以要使用適配器名稱，而不是接口名稱。這表明隊列在某個點上已經(jīng)全滿。 * S/W 發(fā)送隊列上的最大信息包 曾經(jīng)在軟件發(fā)送隊列中排隊等待的外發(fā)信息包的最大數(shù)量。這個字段統(tǒng)計所有由于硬件或是網(wǎng)絡故障造成的不成功發(fā)送的次數(shù)。最重要的輸出字段采用高亮顯示。下面的例子顯示的是 netstat v 命令的 TokenRing 和以太網(wǎng)部分，其他的接口部分也是類似的。至于特定于接口的報告，可以使用 tokstat、entstat、fddistat 或者是 atmstat 命令。在 AIX 和后來的系統(tǒng)中，高限值可以根據(jù)系統(tǒng)中的 RAM 數(shù)量進行比例縮放。緩沖區(qū)歸還給系統(tǒng)時，freed 列就會進行增一操作。下一次再收到請求緩沖區(qū)時，就會把它從自由列表中去除，這樣就避免了鎖定的動作開銷。并不是解除這個緩沖區(qū)的鎖定，把它歸還給系統(tǒng)，而是把它置放在一個基于緩沖區(qū)大小的自由列表中。為了有助于跟蹤故障，可以把 no 命令參數(shù) net_malloc_police 設置為 1，在使用 trace 命令時可以使用標識為 254 的跟蹤 hook。這樣就會使得請求方進入睡眠狀態(tài)，但不會作為被拒絕的請求進行計數(shù)。如果接收到一個請求時沒有可用的緩沖區(qū)，那么這個請求很可能會被刪除（如果要查看適配器是否真的刪除了包，請參閱『適配器統(tǒng)計信息』）。而且，如果當前分配的網(wǎng)絡存儲器的大小是 thewall 的 85% 的范圍內(nèi)，您或許想要增加 thewall 的值。這種情況下失效的計數(shù)器不會執(zhí)行增一操作，但 delayed 列會執(zhí)行增一操作。AIX ，就增加了 delayed 這個列。如果 netstat m 命令表明，向 mbuf 或群集器的請求失敗或是被拒絕，這時您或許想增加 thewall 的值，這可以通過 no othewall= NewValue 命令來實現(xiàn)。需要更改 /etc/ 文件然后重啟系統(tǒng)，就可以實現(xiàn)設定。如果沒有顯示被拒絕的 mbuf 請求，那么可以肯定 SMP 系統(tǒng)在運行 版本或是更晚版本的操作系統(tǒng)，為了性能方面的原因，缺省設定為關閉全局的統(tǒng)計信息。netstat m顯示 mbuf 存儲器管理程序所記錄的統(tǒng)計信息。依次生成了兩個報告，一個是對指定接口，一個是對所有可用的接口（Total）。對于一個指定的接口，它提供的信息和 netstat i 命令類似，并按給定的時間間隔通報。netstat i Znetstat 命令對所有 netstat i 命令的計數(shù)器進行清零。 xmt_que_size 的大小可以通過下面的命令來檢查： lsattr El adapter * 如果沖突的比率比 10% 要大，即是，Coll / Opkts 那么網(wǎng)絡的使用率就比較高，這時或許就有必要重新組合或是分區(qū)。下面時一些調(diào)諧的準則： * 如果輸入信息包中的錯誤次數(shù)比輸出信息包總數(shù)的 1% 還要大（從 netstat i）命令可以看出，即是說，Ierrs x Ipkts 那么就運行 netstat m 命令來檢查存儲器的不足。 Coll 檢測到的信息包沖突的次數(shù)。 Oerrs 輸