【文章內(nèi)容簡(jiǎn)介】 ueue Length: 0Current HW Transmit Queue Length: 0General Statistics:No mbuf Errors: 0 Lobe Wire Faults: 0Abort Errors: 12 AC Errors: 0Burst Errors: 1 Frame Copy Errors: 0Frequency Errors: 0 Hard Errors: 0Internal Errors: 0 Line Errors: 0Lost Frame Errors: 0 Only Station: 1Token Errors: 0 Remove Received: 0Ring Recovered: 17 Signal Loss Errors: 0Soft Errors: 35 Transmit Beacon Errors: 0Driver Flags: Up Broadcast Running AlternateAddress 64BitSupport ReceiveFunctionalAddr 16 MbpsIBM PCI Tokenring Adapter (14103e00) Specific Statistics:Media Speed Running: 16 Mbps Half DuplexMedia Speed Selected: 16 Mbps Full DuplexReceive Overruns : 0Transmit Underruns : 0ARI/FCI errors : 0Microcode level on the adapter :001PX11B2Num pkts in priority sw tx queue : 0Num pkts in priority hw tx queue : 0Open Firmware Level : 001PXRS02下面要講的是高亮顯示的字段： * 發(fā)送和接收錯(cuò)誤 這個(gè)設(shè)備所遇到的輸入 / 輸出錯(cuò)誤數(shù)量。這個(gè)字段統(tǒng)計(jì)所有由于硬件或是網(wǎng)絡(luò)故障造成的不成功發(fā)送的次數(shù)。 發(fā)送不成功也可以降低系統(tǒng)的性能。 * S/W 發(fā)送隊(duì)列上的最大信息包 曾經(jīng)在軟件發(fā)送隊(duì)列中排隊(duì)等待的外發(fā)信息包的最大數(shù)量。 如果排隊(duì)等待的最大發(fā)送量和當(dāng)前隊(duì)列的大?。▁mt_que_size）相等，這表明隊(duì)列的大小不合適。這表明隊(duì)列在某個(gè)點(diǎn)上已經(jīng)全滿。 為了檢查隊(duì)列的當(dāng)前大小，可以使用 lsattr El 適配器命令（比如，這里的適配器可以 tok0 或是 ent0）。因?yàn)殛?duì)列是和設(shè)備驅(qū)動(dòng)程序及接口的適配器相關(guān)聯(lián)的，所以要使用適配器名稱，而不是接口名稱。使用 SMIT 或者 chdev 命令可以改變隊(duì)列的大小。 * S/W 發(fā)送隊(duì)列溢出 外發(fā)信息包的數(shù)量從軟件發(fā)送隊(duì)列中溢出。除零以外的任何值和當(dāng) S/W 發(fā)送隊(duì)列的最大信息包達(dá)到 xmt_que_size 值的情況都需要同樣的操作。必須增加發(fā)送隊(duì)列的大小。 * 廣播信息包 廣播信息包的數(shù)目接收無(wú)誤。 如果廣播信息包的值較高，就把它和接收信息包的總數(shù)相比較。接收到的廣播信息包應(yīng)該比接收到的信息包總量的 20% 還要小。如果其值較高，可能暗示著網(wǎng)絡(luò)的負(fù)載較重，在使用多點(diǎn)傳送。使用 IP 多點(diǎn)傳送可以把信息發(fā)送到一組主機(jī)上，而不需要對(duì)每一個(gè)工作組成員進(jìn)行地址標(biāo)記和單獨(dú)發(fā)送信息。 * DMA 超限 當(dāng)適配器使用 DMA 把信息包放入系統(tǒng)內(nèi)存而且傳輸過(guò)程沒(méi)有終止時(shí)， DMA 超限統(tǒng)計(jì)信息會(huì)進(jìn)行增一操作。有可用的系統(tǒng)緩沖區(qū)可以放入信息包，但 DMA 操作不能完成。當(dāng) MCA 總線對(duì)于適配器來(lái)說(shuō)過(guò)于繁忙，不能夠?qū)π畔褂?DMA 時(shí)會(huì)出現(xiàn)這種情況。在一個(gè)重負(fù)載的系統(tǒng)中，適配器在總線上的位置是很關(guān)鍵的。標(biāo)準(zhǔn)情況下，總線上較低插槽號(hào)的適配器由于擁有較高的總線優(yōu)先權(quán)，使用的總線量很大，以至于在較高插槽號(hào)的適配器不能接收到服務(wù)。尤其是當(dāng)較低插槽的適配器是 ATM 或是 SSA 適配器時(shí)，更是這種情況。 * 最大沖突錯(cuò)誤 由于過(guò)多沖突導(dǎo)致的不成功發(fā)送的次數(shù)。遇到的沖突次數(shù)超過(guò)了適配器上的重試次數(shù)。 * 最近的沖突錯(cuò)誤 由于上次沖突錯(cuò)誤造成的不成功發(fā)送的數(shù)量。 * 超時(shí)錯(cuò)誤 由于適配器報(bào)告超時(shí)錯(cuò)誤導(dǎo)致的不成功發(fā)送的數(shù)目。 * 單獨(dú)沖突計(jì)數(shù) 在發(fā)送過(guò)程中有單獨(dú)沖突的外發(fā)信息包數(shù)量。 * 多路沖突計(jì)數(shù) 在發(fā)送過(guò)程中有多路沖突的外發(fā)信息包數(shù)量。 * 接收沖突錯(cuò)誤 在接收過(guò)程中有沖突錯(cuò)誤的接入信息包的數(shù)量。 * 無(wú) mbuf 錯(cuò)誤 設(shè)備驅(qū)動(dòng)程序沒(méi)有可用 mbuf 的次數(shù)統(tǒng)計(jì)。這通常發(fā)生在接收操作中，驅(qū)動(dòng)程序必須內(nèi)存緩沖區(qū)來(lái)處理入站信息包的情況下。如果所請(qǐng)求大小的 mbuf 池為空，這個(gè)信息包就會(huì)被刪除?？梢允褂?netstat m 命令來(lái)進(jìn)行驗(yàn)證，增加 thewall 的參數(shù)值。 No mbuf Errors 的值是由接口指定的，和 被拒絕的 mbuf 請(qǐng)求 不相同（在 netstat m 命令的輸出中）。比較使用 netstat m 命令和 netstat v 命令（以太網(wǎng)和 TokenRing 部分）的值。為了確定網(wǎng)絡(luò)性能問(wèn)題，檢查所有的錯(cuò)誤輸出（在 netstat v 命令的輸出中）。附加的準(zhǔn)則： * 為了檢查過(guò)載的以太網(wǎng)絡(luò)，要做一些計(jì)算（從 netstat v 命令中）：（最大沖突錯(cuò)誤 + 超時(shí)錯(cuò)誤）/ 發(fā)送信息包量 如果結(jié)果大于 5%，就需要重新改組網(wǎng)絡(luò)來(lái)平衡負(fù)載。 * 高網(wǎng)絡(luò)負(fù)載也表明了另一種情況（從 netstat v 命令中）： 如果 netstat v 命令輸出（對(duì)于以太網(wǎng)）中的沖突總量大于總傳輸信息包量的 10%，如下所示：沖突數(shù)量 / 發(fā)送的信息包量 netstat p protocol顯示由協(xié)議參量（udp、tcp、ip、icmp）所指定值的統(tǒng)計(jì)信息，要么是一個(gè)協(xié)議所熟悉的名稱要么是它的一個(gè)代名。在 /etc/protocols 文件中列出了一些協(xié)議名稱和它們的代名。一個(gè)空響應(yīng)表明，沒(méi)有要報(bào)告的數(shù)據(jù)。如果沒(méi)有統(tǒng)計(jì)程序，那么協(xié)議參量指定值的程序報(bào)告就是不可知的。下面的例子顯示的是 ip 協(xié)議的輸出： netstat p ipip:: 491351 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size data length 0 with header length data size 0 with data length header length 0 with bad options 0 with incorrect version number 25930 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 12965 packets reassembled ok 475054 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded 3332 packets not forwardable 0 redirects sent 405650 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 5498 output datagrams fragmented 10996 fragments created 0 datagrams that can39。t be fragmented 0 IP Multicast packets dropped due to no receiver 0 ipintrq overflows下面要提到的是高亮顯示的部分： * 接收到的信息包總量 接收到的 IP 數(shù)據(jù)報(bào)總數(shù)。 * 無(wú)效報(bào)頭校驗(yàn)和或刪除的段 如果輸出表明無(wú)效報(bào)頭校驗(yàn)和 或 刪除段 是由于重復(fù)或超出空間造成的，這就表明網(wǎng)絡(luò)傳輸信息包出現(xiàn)謬誤或是設(shè)備驅(qū)動(dòng)程序接收信息包的隊(duì)列沒(méi)有足夠大。 * 收到的段 收到的段總數(shù)。 * 超時(shí)后刪除的段 如果超時(shí)后刪除的段為非零，那么 ip 段的計(jì)數(shù)時(shí)間在所有的數(shù)據(jù)報(bào)段到達(dá)之前就會(huì)因?yàn)榫W(wǎng)絡(luò)繁忙而終止。為了避免這種情況，可以使用 no 命令來(lái)提高 ipfragttl 的網(wǎng)絡(luò)參數(shù)值。另一個(gè)原因可能是 mbuf 的不足造成的，這就要增加 thewall的參數(shù)值。 * 從該主機(jī)發(fā)送的信息包 由這個(gè)系統(tǒng)創(chuàng)建并發(fā)送出去的 IP 數(shù)據(jù)報(bào)數(shù)目。這個(gè)計(jì)數(shù)不包括轉(zhuǎn)發(fā)的數(shù)據(jù)報(bào)（由流量轉(zhuǎn)發(fā)）。 * 創(chuàng)建的段 發(fā)送 IP 數(shù)據(jù)報(bào)時(shí)系統(tǒng)中創(chuàng)建的段的數(shù)目。查看 IP 的統(tǒng)計(jì)量時(shí)，參閱一下收到的信息包和收到的分段的比率。對(duì)于小的 MTU 網(wǎng)絡(luò)有一個(gè)準(zhǔn)則，如果有 10% 或者更多的信息包進(jìn)行了分段，那么您就應(yīng)該進(jìn)一步調(diào)查以確定其原因。如果有很大數(shù)量的分段，那表明遠(yuǎn)程主機(jī) IP 層上的協(xié)議正在向 IP 傳輸比接口的 MTU 值要大的數(shù)據(jù)。網(wǎng)絡(luò)路徑中的網(wǎng)關(guān)或路由器可能也有比網(wǎng)絡(luò)中其他節(jié)點(diǎn)小得多的 MTU 值。對(duì)于發(fā)送的信息包和創(chuàng)建的段這也同樣適用。分段會(huì)導(dǎo)致 CPU 的額外負(fù)載，所以確定它的起因很重要。要知道一些應(yīng)用程序本身就能夠?qū)е路侄?。比如，一個(gè)發(fā)送小數(shù)量數(shù)據(jù)的應(yīng)用程序就能夠?qū)е鲁霈F(xiàn)分段。然而，如果您知道應(yīng)用程序正在發(fā)送大量的數(shù)據(jù)，同時(shí)仍然出現(xiàn)分段，就需要確定它的起因。然而，如果您知道應(yīng)用程序正在發(fā)送大量的數(shù)據(jù)，同時(shí)仍然出現(xiàn)分段，就需要確定它的起因。可能是因?yàn)槭褂玫?MTU 大小不是系統(tǒng)中所配置的 MTU 大小。下面的例子顯示的是 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)計(jì)量： * 無(wú)效校驗(yàn)和 無(wú)效校驗(yàn)和可能是由于硬件板卡或是電纜故障造成的。 * 由于無(wú)套接字導(dǎo)致的刪除 那些沒(méi)有打開(kāi)端口的套接字所接收到的 UDP 數(shù)據(jù)報(bào)總數(shù)。因而，肯定會(huì)發(fā)送 ICMP 目標(biāo)地址無(wú)法到達(dá) 端口無(wú)法到達(dá)的信息。但是如果收到的 UDP 數(shù)據(jù)報(bào)是廣播數(shù)據(jù)報(bào)，就不會(huì)產(chǎn)生 ICMP 錯(cuò)誤。如果這個(gè)值較高，就需要檢查應(yīng)用程序如何如何處理套接字的。 * 套接字緩沖區(qū)溢出 套接字緩沖區(qū)溢出可能是由以下原因造成：發(fā)送和接收 UDP 套接字不足、nfsd 守護(hù)程序太少或者是 nfs_socketsize、udp_recvspace 和 sb_max 值太小。如果 netstat p udp 命令表示套接字溢出，那么您或許需要增加服務(wù)器端 nfsd 守護(hù)程序的數(shù)量。首先，檢查受 CPU 或 I/O 飽和度影響的系統(tǒng)，并使用 no a