這是偶99年翻譯的SUN的網絡管理員(SA-387)的東東(6)

呵呵，接著貼，好久沒這么爽了，
我粘!!



第十章   性能概念

目標
通過本章的學習，你將會學到：
l 定義性能
l 描述一個重復的過程來標識和解決一個性能問題
l 描述通常的應用，系統及網絡活動的性能瓶頸
介紹
——什么是性能
在一個計算機環境里，性能被定義成：用來執行一個最小資源消耗和最快反應時間的的這項活動的能力。
——性能活動層
響應時間也許會在以下的級別中與差勁的性能產生沖突。
l 應用層
l 內核層
l 系統配置層
l 網絡層
性能
每一個層所完成的任務會影響其它活動層的性能指數。在一個活動層增強性能也會使其它層有所提高。
——為何要對性能進行調節
調節性能將會使你：
l 對更好的性能請求做出應答
l 對網絡和服務做個評價
l 可以容量做個計劃
——性能瓶頸
在應用，內核，系統及網絡活動層這些對終端用戶，程序，或系統的響應有著關鍵影響的資源就是瓶頸。
性能調節的過程
全部的性能調節就是最大可能的去除反向的沖突所造成的影響。性能調節是一個反復的使用幾個階段來標識和解決一個性能問題的過程。
——觀察問題
性能問題的特征就是由直接觀察得出或由終端用戶質詢得出。如果問題不能被直接觀察到，那么終端用戶會保持一個記載相關問題信息的記錄。舉個例子來說，如果網絡存取變慢，可以查看日志的入口時刻。其它一些有用的工具會被繼續討論。
不要試圖去解決在觀察時期所產生的性能問題。我們的目的是在試圖解決一個性能問題前能對問題有個充分的理解。
——建立度量
一個性能的度量是可以測量的，它由網絡的管理者和終端用戶共同同意的。在可測量方面能用狀態來表示，是性能的目的。
性能的度量設置了終端用戶和系統管理者的期望值，并且他們盡量避免在性能調試周期中的誤解和不必要的反復。
——獲取數據
與性能問題相關的信息在這個階段獲取。數據的獲取與內核，系統，網絡及應用級的活動相關；每個方面也許需要唯一的命令來獲取信息。
在這個階段，與系統，網絡和應用的監視命令相關的知識非常重要，也就是能夠對網絡的瓶頸有一個基本的理解。
——識別瓶頸
在前幾個階段中收集的信息被用來分析和解釋以標識可能引起的性能問題瓶頸的原因。
所有瓶頸的號碼可能會很明顯。識別出瓶頸可以減少系統沖突，并最大化的增強系統性能。
——測試假設
一個可能的網絡瓶頸的解決方案產生于對關鍵系統和網絡資源的相關性的理解?；谶@個理解，系統管理者可以評估移除或減少的調節所需。
首先發現一個臨時的解決方案，或調節動作，是大多數服務器瓶頸的第一步。另外，對于每個重復的性能調節過程來說，可能只有一個調節動作執行。
——分析數據
數據獲取動作被重復，使用同樣的條件，系統，網絡和應用監視命令在初始數據獲取階段。在性能問題首先獲取外觀上幫助的地方精確的復制活動級別和條件來評測一個性能調節動作所起的作用。
收集的信息要對最初捕獲的數據進行對比，以便于在去除或減輕系統的瓶頸后評測性能調節的作用。
——實現解決方案
決定是否永久的執行性能調節動作要基于它對系統的效用。理論上來說，每個性能調節會得到一個肯定的結果，但，有些時候，一次性能調節可能會毫無作用而言。另外，要注意，在每次的性能調節后不要引入新的不被注意的性能瓶頸。
The entire process is repeated any number of iterations required to meet the performance metrics established during the initial pass.
通常的性能瓶頸
——系統配置
在客戶端或服務器上的關鍵性系統資源也會表現出潛在的系統瓶頸。理解CPU，磁盤，以及內存資源間的關系對正確的識別出系統瓶頸是至關重要的。
——瓶頸對比
內存速度可以用納秒來計算，而磁盤的速度則要用毫秒來計算。如果我們以一個乘數和以秒計的內存速度狀態做一計算，則會有以下的關系。
數據通過系統資源到達到CPU進行處理，存取時間會大輻度增長。
—— CPU
CPU提供執行周期用來處理很多任務，包括網絡服務如NFS服務。一個負荷很重的CPU必須對所有進程共享執行周期，并且每個進程在一個執行隊列中等待。較長的等待時間，或潛在的，也許都會影響到進程提供足夠響應的能力，這也是一個瓶頸。
——磁盤
在當一個系統不能有足夠快的速度對磁盤進行讀寫時，這也就是磁盤瓶頸。這在NFS服務器所支持的客戶端是很常見的問題，因為服務器磁盤的文件系統所需要的數據往往要通過很過不同的物理位置。
——內存
在執行中，一個進程所需要的數據可以位于內存中或本地磁盤中。如果CPU直接從內存中讀取數據，則瓶頸會極大的減小，因為內存的存取速度要比磁盤的存取速度快得多。內存少會造成對磁盤的大量讀取及后來的瓶頸。
——虛擬內存
Solaris操作系統使用磁盤區做為虛擬內存，并把它做為對物理內存的擴展。分頁是一個從內存到磁盤移動頁或從磁盤到內存稱動頁的進程。重要的是在系統分頁過程中，磁盤帶寬會被消耗，因為必須對磁盤進行讀寫數據，又可能會為性能引入瓶頸。
 Swapfs是一個Solaris 2.x系統中假的文件系統，它提供虛擬的交換空間。它在磁盤設備的交換空間上使用主內存來為匿名內存做背向存儲，或者一個進程的各個部分包括虛擬或未初始化的數據。
當一個進程啟動時，如果內存不足，則把它分配到內存事件的背向空間。在低內存的狀態下，系統試圖移動這些進程的部分（未初始化的，虛擬數據，和不是進程的文檔，這些都可以從一個本地或遠程文件系統來獲?。奈锢韮却娴酱疟P上已經劃分出來的區域，或交換空間。
——虛擬內存之 swapfs
swapfs 用來捕獲諸多請求，并在背向空間為系統提供假冒的磁盤地址。這又有了運行時超出背向存儲空間或交換空間在運行超出主內存之前，甚至不能通過物理內存來執行一個進程，這個問題是很廣泛的（在 SunOS 4.x操作系統中）。
在低內存的狀態下，系統會試圖移動進程的頁到假冒的磁盤地址去，swapfs 會再次捕獲這些請求。如果磁盤上的交換空間可用，swapfs 會重新發布有效的磁盤地址，并且頁會由內存移動到磁盤。如果磁盤上的交換不可用，那么 swapfs 則會簡單的返回一個“out of swap space” 的錯誤信息。
——虛擬內存之 tmpfs
tmpfs 是Solaris 2.x 的另一種文件系統類型。它映射了磁盤對虛擬內存的固有目錄如（/tmp）。在物理內存資源豐富的情況下，使用 tmpfs 可以使對目錄的讀寫存取時間大幅減少，因為這可以避免磁盤設備的等待時間。但是，如果內存過小，那么 tmpfs 中的文件被交換出磁盤，它對固有磁盤的優勢也就不復存在了。
使用 tmpfs 只適用于易變的數據，如在 /tmp 中的文件。系統掉電將會毀掉所有在tmpfs中的數據。
——內核
系統內核使用很多的緩存來存儲那些被頻繁存取的數據。每個緩存中的信息被存儲在內核的內存中，可以減少存取時間。先前版本中的SunOS軟件使用靜態的內核緩存大小，有些時間，這需要重新來調整。
在Solaris 2.x系統環境中，基于安裝的系統內存來動態的創建優化的內核緩存大小，在大多數情形下不必要調整。
——網絡
——網絡之存取方式
CSMA/CD 即指，所有的設備連接在單一的介質上，每次只能有一次傳輸，而且他們可以同時接收。如果兩個設備試圖在同一時刻同時傳輸，那么，沖突將會被檢測到，兩個設備都將會等待一個隨機時間段（很短）后再次發次。
——網絡之網絡負荷
這是在數據包的傳輸，碎片和阻塞信號所消耗的網絡帶寬（通信連接中的信息容量）的百分率。
如果沒有足夠的可用帶寬，它將影響到一個服務器用來對客戶請求提供足夠的響應時間的性能，也就是會引入一個瓶頸。
以太網絡是一個只能負荷40%的低效網絡（這個值是理論上網絡帶寬的消耗值）。

——網絡之以太網碎片
以太網的碎片是一個損壞的幀。它是由兩個主機試圖在同一時刻的傳輸造成的。信號沖突所致的斷裂或碎片必須重傳。
以太網的碎片需要信息的重新發送，這導致了網絡負荷的加重。舉個例子來說，一個2版本的NFS服務器要應答所讀到的8K信息的請求。一個8K的NFS ver 2 信息由六個以太幀構成（以太網的MTU的值為1500字節），按順序傳輸。如果這六個幀的任何一個壞掉了，全部的8K信息都要重傳。
不止是消耗網絡帶寬，大量的碎片是網絡高負荷的暗示，因為他們產生于大量主機的試圖同時傳輸。大量的沖突被檢測到則說明在局域網上沒有足夠的網絡帶寬可以提供給所有的主機。
如果只有極少的或沒有沖突，那么主機對網絡的存取是沒有競爭的。
——網絡之阻塞信號
以太網的阻塞信號是主機在檢測到沖突后向網絡發送的廣播。阻塞信號指明了網絡負荷。
——網絡之網絡延遲
一個需要存取網絡的主機如果檢測到以太網正在使用，它將會延遲傳輸。它會繼續監視網絡直到網絡變為可用。一個忙的，高負荷的網絡會經常強迫主機推遲傳輸。
——網絡之差勁的以太應用軟件
以太網使用的存取方式（10M/s，CSMA/CD）不適合幾種類型的應用，如：持續的大體積文件系統的備份，介質復制，或連續的大的數據傳輸。
這些網絡負荷的類型快速的消耗了網絡帶寬，潛在的迫使其它主機延遲網絡傳輸并降低所有網絡的響應和存取時間。
因為這些操作屬于帶寬密集型，也可能導致網絡的超負荷運載，使其不能再對傳輸進行處理。
——網絡之空閑以太應用軟件
Sun 的網絡趨勢于突發性的，除非他們是密集型的網絡應用如大體積的數據傳輸，備份等。以太網也可以很好的適應突發性的傳輸，包括零星的文件傳輸，命名服務的查找，窗口下的客戶對服務器的交互，及一個NFS分布式的文件系統。
應用：NFS
NFS應用允許通過網絡使用分布式的文件系統。這是在Sun的網絡中通常使用的服務級應用。
在網絡和系統級別中所出現的瓶頸可能會潛在的影響NFS的性能。這在性能的調整過程中來標識和尋找真正的NFS的瓶頸的初始原因是非常重要的。
——NFS 版本 2
NFS在TCP/IP模式中在應用層使用Sun 的RPC服務。NFS的傳輸機制是UDP。UDP是一個無狀態的協議，它無需使用順序發送。流控制和其它數據的可靠性機制則由定向連接協議如：TCP來實現。因此，在系統級別處理UDP的包只占用最少的CPU資源。
因為UDP是無狀態類的協議，一個NFS用戶經常面對如下的錯誤信息：“NFS server not responding,still trying”而拿不定主意，不知道瓶頸在網絡還是在主機？進一步說，NFS服務器給客戶端提供無狀態信息，客戶沒有辦法知道一個未響應的服務器是慢還是已經斷線了。
——NFS 版本 3
在1992年，IBM,Digital,SunSoft和其它幾個網絡商組織在一起開始了定義下一個NFS的修訂版。結果是產生了NFS Version 3。NFS版本3在NFS版本2上有了實質性的增強。增強的有以下幾個方面：
l 增強了客戶端的寫入的量
l 降低了服務器的負荷
l 增加了客戶端的磁盤緩存
l 在NFS服務器上支持大文件（幾個G字節）
NFS最初被設計為使用UDP作為既可在本地網又可在廣域網通信的傳輸協議。選擇
UDP是因為它比TCP提供了更好的性能。UDP在局域網內工作得很好，但在廣域網的使用中有些局限性。
NFS 版本 3
——增強了客戶端的寫入的量
NFS版本3協議提供了更好的選擇來增加寫入的量，通過去除同步寫的請求而保留了關——開的簡單形式。NFS 版本3的客戶端發送一個寫請求給服務器，隨即，它提交了一個確認請求給服務器，這將導致服務器在同一時間寫入所有數據到可靠的空間。這就是我們所知道的安全的異步寫功能。因為客戶端寫入服務器的緩存，寫入的量提高了，并且寫請求完成的更快了。
——減少了網絡負荷
NFS版本2的客戶單獨的查詢服務器上所有目錄入口的文件和目錄名列表及屬性信息在一個查找請求中。NFS返回一個文件修改前和修改后的屬性，所以客戶可以檢測到服務器上一個文件或目錄的改變，而不需要發送一個單獨的 GETATTR 調用。這樣，大大減少了客戶端的 GETATTR的調用，也就減少了網絡和服務器的負荷。
——增強了客戶的磁盤緩存（caching）
項目“caching”是指文件數據的臨時存儲在一個快速存取的本地存儲區稱為緩存。一旦文件數據被緩存后，隨后的客戶端請求直接到達緩存而不再需要經過網絡的數據傳輸。緩存在內存中的數據被劃分為8K每塊。
然而，可用來進行緩存的內存數量通常都很有限。一個解決方法就是通過CachsFS來把本地的磁盤做為一個緩存。CacheFS，是Solaris 2.3后的工具，通過使用客戶端的本地磁盤可以為NFS增加大量的可用緩存空間。它緩存文件數據在大于64K字節的塊中，也緩存整個的目錄，它還緩存象征性的鏈接。擴大緩存的空間也就是說客戶可以更快的存取數據，也可以更少的向服務器發出請求信息。
——支持大的文件系統
NFS版本2支持文件的偏置，文件系統最大為32位或文件的最大值為2.1GB。在磁盤存儲器持續下跌的價格和磁盤容量的不斷增大，不斷增長的用戶對文件的需求，文件系統的容量必須大于2.1GB。
NFS版本3支持64位的文件偏置，最大支持文件和文件系統到18MT。NFS版本3的實現由它們把支持的操作系統限制。Solaris 2.5軟件不支持64位文件偏置；UFS文件系統只支持文件偏置到40位，也就是1TB。
NFS版本3的功能
——NFS的讀請求
以下描述了NFS的對讀的處理步驟
1． 在執行中客戶進程請求數據。如果請求不能完成，進程不能繼續。
2． 客戶端檢查數據是否已經存儲在內存或緩存中。如果數據可用，那么進程使用這個數據并重新開始執行。
如果數據存在于客戶端的內存中，那么，數據將會以8k每塊進行存??；如果數據存在于客戶端的緩存系統（CacheFS），那么，數據將會以64k每塊進行存取。
另外，NFS客戶端將會維持一個文件的緩存甚至在它關閉之后。因為，在通常情況下，當一個文件被重新打開時，讀請求將會被存儲在本地緩存數據滿足。
3． 如果數據沒有被預先存儲在內存中，那么客戶端必須在服務器上來獲得它?？蛻舳诵枨蟮臄祿ㄟ^一個NFS 的RPC服務。
4． RPC 信息通過網絡進行發送。
5． RPC信息被服務器接收。服務器調度一個 nfsd 來為請求服務。nfsd 是一個運行在服務器上的守護進程并且接受客戶端的RPC調用。
6． 服務器檢測數據是否已經存儲在內存中。如果數據已經存在，那么服務器將封裝數據到一個RPC信息中，發給客戶端?？蛻舳私邮盏竭@個信息，并把數據拷貝到有效的內存中，并且客戶進程使用它來重新開始執行。
如果文件被繼續讀取，NFS客戶端可以通過一個叫 readahead 的進程來預料將來的數據需求。Readahead 允許客戶端使用它的本地高緩來存儲預料的將來的信息。
7． 只要數據保留在內存中，那么，隨后同樣的數據請求將會在本地完成。
8． 如果數據在內存中不可用，那么，服務器將初始化一個磁盤操作來檢索數據。數據將被拷貝到有效的內存中并被封裝在一個RPC信息中，發送給客戶端?？蛻舳私邮盏叫畔?，拷貝數據到有效的內存中，并且客戶端使用它來重新開始執行。
如果服務器接收到對同一數據的另一個請求，它將避免直接從內存中讀取數據的磁盤存取。
——NFS緩存一致性的校驗
回憶一下，在一個客戶發送一個NFS讀RPC之前，它檢測在前一個請求后，數據是否已經存儲在內存中。如果數據是有效的，那么進程將使用它并重新開始執行。但是，當它被初始化的拷貝到客戶端的內存后，服務器上的數據改變了，該如何做？
客戶端使用一個緩存一致性的校驗來證實內存中存儲的數據內容。
1． 客戶端在內存中發現一個請求數據的拷貝并且由時間限制被緩存數據的有效性來管理緩存的一致性。拿文件來說，介于3到60秒的時間變化，依賴于刷新的頻率。相似的，在目錄中維持的緩存的一致性可以限制在30秒到60秒。校驗的限制時間可以進行配置在CacheFS 選項中。
2． 如果數據已經存儲的時間超過了校驗的時間限制，客戶端發送一個NFS的 getattr 請求來對比修改的數據和緩存數據的時間戳和服務器上的數據。
Bear -> Zebra NFS  C GETATTR3 FH=009F
Zebra -> bear NFS R GETATTR3 OK
Bear -> zebra NFS C GETATTR3 FH=009F
Zebra -> bear NFS R GETATTR3 OK
3． 如果緩存數據的改變的時間戳與服務器上的改變的時間戳相同，客戶端對另一個時間間隔延長它的生存期，客戶端的進程重新執行。
4． 如果改變的時間戳不同，數據將會被舍棄，客戶端為一個新的數據拷貝發送一個NFS讀請求。
——NFS寫請求
以下描述了一個NFS的寫處理：
l 使用安全的異步寫，在數據中的幾個寫操作結果將會被存儲在客戶端的本地緩存中。
l 數據通過異步寫方式穩定的寫入到服務器中，相關的位被設置為 FALSE，通常，當一個寫操作通過頁的邊界時，數據被寫入到頁面大小的塊。
l 如果返回的應答的提交段被設置為TRUE，客戶將會標識寫請求已經執行，不需要更進一步的操作。如果提交被設置為FALSE，則指出這個緩存還沒有和服務器的磁盤同步，客戶需要來標志緩存來指明服務器端有一個活動的緩存拷貝，不需要發送一個新拷貝，但是需要一個新的提交。
一個緩存有三個狀態：壞的，執行但需要一個提交，已經執行。
l 寫被認為是安全的，因為數據的狀態信息由客戶端維護，指明了數據是否已經被成功存儲。如果在一個提交操作前，服務器斷掉，客戶將會知道是否需要重新提交一個寫請求當服務器重新上線的時候。
——NFS 重發
NFS重發是由一個客戶端無法忍受一個慢速的服務器應答所產生的。
l 在發送一個信息給服務器之后，客戶端在一個單位的時間內預料返回的應答。
l 如果在有效的時間期內沒有接收到肯定的應答，客戶端重發請求，timeo 乘2，一個計數器，請求時間的響應值被發送，值增加一。
l 當重發的數量等于由retrans 值指定的值時，（指定一個NFS的載入點可以從命令行執行也可在客戶端的載入表或圖中執行），有一件或兩件事情將會發生。
l 如果系統由軟選項載入，客戶端發送一個請求NFS文件系統的錯誤，并將提示返回給使用者。如果系統由硬選項載入，打印警告信息： NFS server not responding并且繼續重試請求。
這也就是所說的主時間周期（major time-out）。
總結
在本章中，你已經學會：
l 定義性能
l 描述一個重復的過程來標識和解決一個性能問題
l 描述在系統配置，網絡和NFS活動層的通常的性能瓶頸問題

solstice 回復于：2003-06-25 16:18:51

第十一章 性能監視 目標 完成本章的學習后，你將能夠： l 描述監視系統，網絡和應用級別負荷的命令 l 計算網絡帶寬消耗的百分比 l 測試NFS客戶/服務器的效率 介紹 本章描述的命令可以幫助你定位和查找網絡，應用程序和系統級瓶頸的故障點。 監視服務器 ——關于命令： /usr/bin/iostat ————磁盤負荷 命令：iostat 報告了終端和（更多有用的）磁盤的I/O活動。Iostat 用來測定一個服務器系統的磁盤負荷。 在下面的例子中，iostat 每5秒來測定一個磁盤的 I/O： # iostat –D 5 輸出的第一行總結了自系統第一次啟動后，I/O的統計。隨后的每行則表現了每隔一個具體的時間的活動。 以下的例子顯示了一個磁盤負荷不平衡的服務器： # iostat –D 5 sd0 sd1 sd2 sd3 rps wps util rps wps util rps wps util rps wps util 0 0 0.0 0 0 0.2 0 0 0.2 19 0 56.5 0 1 2.6 0 0 0.0 0 0 0.0 0 17 99.2 4 0 8.0 0 0 0.0 0 0 0.0 14 0 89.3 0 2 2.3 0 0 0.0 0 0 0.0 7 17 78.0 . . 對比 sd0,sd1,sd2和sd3的util字段。注意，磁盤sd3被高負荷的使用著，并且讀和寫的I/O是混合的。其它磁盤 sd0,sd1,和sd2未被充分使用。 下面的這個例子是一個磁盤負荷比較平衡的服務器： # iostat –D 5 sd0 sd1 sd2 sd3 rps wps util rps wps util rps wps util rps wps util 6 8 8.0 10 9 40.2 7 6 20.2 9 0 25.5 0 1 2.6 8 4 36.8 5 14 45.0 7 9 39.2 4 0 8.0 7 4 27.0 6 12 37.0 4 7 29.3 0 2 2.3 4 6 23.0 0 8 23.3 7 1 38.6 . . iostat 是一個有用的服務器配置命令。用來在每個磁盤上測量利用的程度和活動（讀/寫）的類型，管理員可以為服務器上的數據選擇最佳位置來共享給使用NFS的客戶端。 例如，當配置一個服務器來支持額外的客戶時，可以iostat 來識別磁盤的可選用的級別。為了保持全部磁盤的負荷平衡，管理員可以使用 iostat 統計來為客戶端的根區，交換區，和體系統結構區，以及終端用戶的home目錄分配空閑的位置。 ——關于命令：/usr/bin/vmstat 命令：vmstat 報告關于進程，虛擬內存，磁盤，中斷，及CPU活動的統計。 更為重要的是， vmstat 可以用來快速的發現CPU和內存的瓶頸，以下舉個例子來說明 vmstat 的輸出。 # vmstat 1 procs   memory page   disk faults cpu r b w swap  free re  mf pi po fr de sr s3 s6  in sy cs us sy id 1 0 5 516 0 0  1 0   0   0   0   0 0  0   9 60  48 4 2 94 0 0 3  75980 0 0 13  184 4 236 0 76 1  0  187  245 127 6 14 80 1 0 4 75984 0 0 0 96 0 40 0 60 0  0  148 152 100 7 5 88 0 0 2 75984 0 0 0 120 0 176 0 53 0  0  131 84 86 6 5 89 ————執行隊列 在字段 procs 下的列描述了在可執行隊列中的進程號。字段 r 表示進程已經裝入內存中。下一個字段 b 描述了不能被執行的進程號，因為這些進程要等待磁盤，終端或網絡的I/O操作來完成。在字段 w 中所表示的是進程已經被交換出去。 ————虛擬內存 字段 sr 指出了每秒中頁守護進程的循環次數。這個進程只在有效的內存很少的情況下才運行。如果每秒的連續值大于20，則說明內存已經不足。 ————CPU的利用率 字段cpu所在的列描述了基于用戶和系統調用的CPU的利用率。連續的低值在cpu的id字段（值低于10）說明CPU非常忙。 許多可獵取的進程被交換出去（如在procs字段中所指明的那樣），內存中的少量的可獵取進程指出了物理內存的缺點。 在例子中，虛擬內存的大負荷使用，磁盤的I/O可能會是系統的瓶頸。 # vmstat 1 procs   memory page   disk faults cpu r b w swap  free re  mf pi po fr de sr s3 s6  in sy cs us sy id 1 0 5 516 0 0  1 0   0   0   0   0 0  0   9 60  48 4 2 94 0 0 3  75980 0 0 13  184 4 236 0 76 1  0  187  245 127 6 14 80 1 0 4 75984 0 0 0 96 0 40 0 60 0  0  148 152 100 7 5 88 0 0 2 75984 0 0 0 120 0 176 0 53 0  0  131 84 86 6 5 89 ——關于命令：/usr/sbin/sar 命令：sar 是系統活動的指示器。Sar 可以交互式的或用批處理方式來報告系統資源的利用率。 ————交互式的報告 以下這個交互式的例子測試了CPU的利用率并且每隔10秒取得一個樣本，共兩個。 # sar 10 2 SunOS  bear 5.5 Generic sun4m  01/20/96 01:53:14 %usr %sys %wio %idle 01:53:24 0 0 0 100 01:53:34 0 1 2 97 Average 0 1 99 # ————批處理方式報告 如果指定 –o ，那么樣本將會保存在一個二進制格式的文件中。 # sar  –o  /tmp/sar.file 10 2 # 文件中收集的信息也許可以用選項 –f 來重新進行。 # sar –f  /tmp/sar.file SunOS bear 5.5 Generic sun4m 01/20/96 01:53:14 %usr %sys %wio %idle 01:53:24 0 0 0 100 01:53:34 0 1 2 97 Average 0 1 99 # 下面使用 sar 的選項來幫助你發現關鍵性系統資源的利用率。 ————磁盤利用率 使用 –d 選項來發現不平衡的磁盤負荷。注意在下面的例子中，字段 %busy 中的磁盤 sd3 比所有其它的設備都要忙。 # sar –d 10 2 SunOS bear 5.5 Generic sun4m 01/20/96 02:03:05 device %busy evque r+w/s biks/s avwait avsery 02:03:15 fd0 0 0.0 0 0 0.0 0.0 sd2 0 0.0 0 0 0.0 0.0 sd3 67 0.7 9 2206 0.0 75.5 02:03:25 fd0 0 0.0 0 0 0.0 0.0 sd2 2 0.2 1 22 88.5 46.1 sd3 69 0.7 9 2182 0.0 79.7 Average fd0 0 0.0 0 0 0.0 0.0 Sd2 1 0.1 1 11 88.5 46.1 Sd3 68 0.7 9 2194 0.0 77.6 # ————虛擬內存 使用選項 –g 來監視虛擬內存的使用。字段 pgscan /s 指出了由守護進程 pageout執行的每秒搜索的頁面數。這個守護進程只運行在有效內存很低的情況下。連續的值大于20每秒說明內存已經不足。 # sar –g 10 2 SunOS bear 5.5 Generic sun4m 01/20/96 02:22:34 pgout /s ppgout /s  pgfree /s pgscan /s %ufs_ipf 02:22:44 1.20 12.08 21.06 23.85 7.06 02:22:54 1.10 9.00 19.30 21.30 10.81 Average  1.15 10.54 20.18 22.58 7.35 # ————執行隊列 使用 –q 選項來查找執行隊列中有多少進程在排隊。字段 runq-sz 中指出了內存中等待執行的進程線數。如果值始終大于2，那么系統限制于CPU。 字段 %runoclearcase/" target="_blank" >cc 表示運行隊列是否被占用。較小的值是比較可取的，因為它表明每個隊列中的進程都被較好的分配了時間。 # sar –q 10 2 SunOS bear 5.5 Generic sun4m  01/20/96 02:35:31 runq-sz %runocc swpq-sz %swpocc 02:35:41 12.6 100 0 02:35:51 12.0 100 0 Average 12.3 100 0 # ————自由內存 使用 –r 選項來查找可用內存頁和交換文件磁盤塊的平均數量。 Freemem 字段指出了每個間隔中能為用戶進程有效使用的內存（在 SPARC結構中為4K）頁的平均數量。 Freeswap 字段顯示了有多少個512字節的扇區是可以為交換使用的。 Freemem 的連續低值（少于安裝內存的6%）則表示有效的內存不夠，和一個可能的瓶頸。 # sar –r 10 2 SunOS bear 5.5 Generic sun4m  01/20/96 02:55:11 freemem freeswap 02:55:22 2686 178006 02:55:32 2208 160269 Average 2447 169151 # ——命令：/usr/sbin/swap 命令：swap 用來顯示使用的交換空間，和在磁盤上增加和移動交換區。 ————顯示交換空間 下面這個例子使用選項 –l 在每個交換設備上顯示全部的磁盤扇區（塊）列表和未使用的扇區（自由）。 # swap –l  swapfile dev swaplo blocks free /dev/dsk/e0t3d0s1 32,25 8 187912 127088 # 默認的交換區是第二個磁盤設備分區包括根分區，就象在例子中顯示的那樣。 ——創建和增加交換區 附加的交換分區可以是規則文件（由命令 mkfile 創建）也可以是磁盤分區。下面的例子用命令： mkfile 來創建一個10M的交換分區。 # mkfile 10m /exp/swap # 附加的交換空間也可以使用命令：swap 的選項 –a 。下面的例子增加一個交換文件，然后更新交換空間列表。 # swap –a  /exp/swap # swap –l  swapfile dev swaplo blocks free /dev/dsk/c0t3d0s1 32,25 8 187912 126920 /exp/swap 8 20472 20472 # ————移除交換區 使用選項 –d 來移除交換區。在這個例子中，先前增加的交換區被移除，并核實調整之后的交換空間。 # swap –d /exp/swap # swap –l  swapfile dev swaplo blocks free /dev/dsk/c-t3d0s1 32,25 8 187912 126920 # 如果交換區有任何活動的磁盤扇區包含交換到進程中的數據，命令： swap 在移除交換區前會安全的對數據進行重新定位。 ——命令：/usr/bin/ps  命令：ps 打印所有活動進程的信息。更重要的是，ps 命令可以查找進程的ID號（PID），（可用來向進程發送終止或掛起的信號），進程狀態（進程是否已經被裝入內存等待執行，交換到磁盤等等），累計的CPU資源消耗（通常用來捕獲失控的進程）。 下面舉例說明 ps 的輸出： # ps –el F  S  UID PID PPID C PRI NI ADDR SZ   WCHAN TTY  TIME CO 8  R  7198  22028 19551 80 1 30 ff7c0000 349   ?   83:53  xl 19 S 0 3 0 80 0 SY ff19d000  0   f00c26ae   ?  265:00 fsfl 8  O 0 26070 26053 14 1 20 ff78c000 142  pts/4  0:00 p 字段S來描述每個進程的狀態（從剩余的秒來說）。下面對每個可能出現的進程狀態做一個描述。 ————進程狀態 l O  進程正在被處理器運行 l S 睡眠狀態：進程正在等待一個事件來完成 l R 可捕獲的：進程正在運行隊列中 l I  空閑的：進程正準備創建 l Z 僵尸進程：進程終止，父進程不必等待 l T 追蹤：進程被一個信號停止，因為父進程正在追蹤于它 l X SXBRK 狀態：進程正在等待更多的主內存 ——命令：/usr/bin.netstat  命令：netstat 顯示了多種網絡關系信息，包括每個網絡接口的傳輸統計。 ————沖突比率 在下面的例子中使用 10秒的間隔來測試包沖突的比率。 # netstat –i 10 input le0 output input (Total) output packets errs packets errs colls packets errs packets errs colls 1929138 0 1590861 3 73176 1946182 0 1607905 3 73176 16 0 1 0   0 16 0 1 0 0 3 0 3 0   0 3 0 3 0 0 一個單一主機的沖突比率是輸出沖突的數量除以總共的輸出包的量。網絡沖突比率按如下的方式計算： l 在所有活動主機上運行這個命令來收集網絡的統計量，用總共的沖突數除以總共的輸出包數就可以得出網絡的沖突比率。 l 沖突的比率被定義為：輸出的沖突數除以總共的輸出包，再乘以100。拿上個例子來說： 73176 / 1590861 * 100=4.6% 的沖突比率。 沖突比率超過5%，則要先考慮網絡的負荷是否過重。 沖突比率超過10%，這是一個超負荷的網絡，要考慮把它分段。 ——命令：/usr/sbin/snoop 命令： snoop 在網絡上捕獲和顯示包的內容。Snoop 可以用來定位許多網絡異常的源和目標如NFS的重發。 這個命令的輸出可以用它所捕獲的大量數據快速的淹沒磁盤的可用空間。超負荷的有用信息包括如下： l 捕獲一個二進制文件 # snoop –o packet.file # CTRL-c 顯示這個二進制文件的內容 # snoop –i packet.file l 只捕獲有關的信息如包含在前120個字節內的包的頭文件 # snoop –s 120 l 捕獲指定的包的數量 # snoop –c 1000 l 捕獲 tmpfs 來避免因磁盤瓶頸撤消的包信息 # snoop –o /tmp/packet.file l 指定過濾器來捕獲指定類型網絡活動 # snoop broadcast l 使用 awk ,sed ,grep ,來解釋和總結 snoop 輸出。 ——命令：/usr/bin/nfsstat 命令：nfsstat 顯示了關于NFS和RPC的內核接口的統計信息。 NFS對決定NFS的客戶/服務器的一個時期內的工作負荷也是很有用的。字段 calls 顯示了NFS的操作數量，也就是服務器提供的服務或客戶端的請求。 # nfsstat –rc Client rpc: Calls badcalls retrans badxid timeout wait newcred timers 186992 7 225 170 166 0 0 370 . #  字段 badxid 顯示了客戶端接收了多少次關于一個單一請求的肯定應答。 字段 retrans 指明了在一個時間周期內，客戶端因沒有接收到一個肯定的應答而重新發送請求的次數。 ————評價NFS的客戶/服務器統計 如果 badxid 和 retrans 值都關閉的話，那么，服務器對客戶端的響應則不夠快速。優化服務器的性能也就相應提高了網絡的性能。 客戶端可查覺到的性能可以通過增加客戶的文件系統表或映射的time-out(timeo)選項值來提高。默認值為11（1.1秒）。網絡的響應時間不會提高，但客戶會體驗到更少的timeout,重新發送，和并發的錯誤信息。 如果 badxid的值比retrans的值小得許多或為0，那么，混合了NFS，RCP的信息沒有到達服務器，網絡或服務器上的網卡是可疑的。 如果重新發送的與全部的調用的比率大于5%（retans/calls *100），重傳率就過高。這可能表示客戶端正在存取一個不同子網或網段的服務器。如果客戶端的數據報在它們到達目標服務器之前導致了過多的重傳，那么它們有可能會被中間的路由或橋取消。 為了更好的適應中間結點的數據報大小的處理能力，NFS的傳輸信息大小可以減少。讀和寫的大小可以通過 nfsstat 加選項 –m 來測定。 # nfsstat –m /mnt/opt from zebra:/opt Flags:vers=3,proto=udp,auth=unix,hard,intr,link,sylink,acl, rsize=32768,waize=32768,retrans=5 Lookups: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) Reads:  srtt=1 (2ms), dev=1 (5ms), cur=0 (0ms) All: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) 注意：如果使用NFS版本3，那么TCP協議將會自動的降低段大小一直到它適合通過”bad routers”。這是在路由器不支持 back-to-back的IP碎片時發行的，這些碎片是由NFS版本2的8k字節的讀和寫產生的。但，只有在客戶端使用UDP時，rsize/wsize會被設小來適應一個MTU，如512或1k字節。 ——重新初始化統計 在命令：nfsstat 中使用選項 -z 來重新初始化統計報告。在下面的例子中，客戶的RPC統計被設置為0。 # nfsstat –rcz Client rpc: Calls badcalls retrans badxid timeout wait newcred timers 5815 0 0 0 0 0 0 39 # ——守護進程 /usr/lib/nfs/nfsd 在Solaris 2.x操作系統中，nfsd 是一個使用內核線程來處理所有的NFS請求的單一進程。如果服務器上沒有足夠的可用線程來服務每個客戶端的請求，客戶端性能也是可以忍受的。 你可以配置兩個線程為每個活動的客戶端機器，或32個每以太網絡。默認為16個線程給每個偶然的NFS用戶。但是，如果一個低終端SPARC類的服務器同時運行幾百個線程還是有些負荷過重的。 調整系統啟動時的nfsds數在腳本：/etc/rc3.d/S15nfs.server或 /etc/init.d/nfs.server ——總結 在本章中，你已經學會： l 描述用來監視系統，網絡和應用級別負荷的命令 l 決定消耗網絡帶寬的比率 l 測試NFS客戶/服務器的效率

lycxlove 回復于：2003-06-25 17:57:37

好呀，怎么沒人頂

Bimm 回復于：2003-06-25 19:06:30

非常有用！

weinylee 回復于：2003-06-25 19:15:21

ding

jye 回復于：2003-06-25 23:09:56

GOOD, VERY GOOD, VERY VERY GOOD. EXCELLENT. AMAGING.

moocher 回復于：2003-06-26 22:07:31

基礎中見精華！

原文轉自：http://www.kjueaiud.com