HPUX性能分析思路Word下载.docx

1、有磁盘的busy值经常大于50吗？对于该磁盘，是否同时存在其avwaitavserv的现象?（因为涉及到physical IO和logical IO的配置平衡，以及buffer page/swap空间/异步读写等问题，磁盘瓶颈很难通过单一因素判断，50只是一个大概的评估标准，要结合具体情况综合分析。有时候，%busy仅仅为20就已经是磁盘瓶颈，而另外的我们认为磁盘工作正常的系统，busy值很可能已达到80）。是 系统很可能存在I/O瓶颈，去到第五步否 基本上认为不存在磁盘瓶颈，去到第六步第五步系统存在磁盘瓶颈。让我们来看看深层原因，该磁盘为swap空间 该磁盘瓶颈很可能是由内存瓶颈间接造成的，

2、去到第六步来确认。 计算问题磁盘的blks/s *该磁盘不是swap空间 512，分析当前的实际应用带宽，并与磁盘柜的设计值比较，作为进一步消除瓶颈的依据。如果现实值与设计值相差太远，说明磁盘环境的拓扑/参数设置可能不合理，要做进一步分析。第六步执行 vmstat interval iterationsvmstat 5 30）1，po值经常大于0吗？2，对于S800系统，（free * 4K） 系統非 CPU Bound。跳到步驟 3。Yes - 系統可能是 CPU、記憶體或 I/O Bound。跳到步驟 2。步驟 2%usr 的值高嗎？大部分系統正常運作的情況是 80% 的 CPU 時間花在

3、使用者時間，20% 則花在系統時間。其他系統正常則使用多於或少於 80% 的使用者時間。 系統可能有 CPU、記憶體或 I/O 瓶頸。 由於使用者程序，系統像是有 CPU 瓶頸。跳到第 3 節，部份 A 調整系統的 CPU 瓶頸。步驟 3%wio 的值是否大於 15？ 請先記住。這可能是磁碟或磁帶遭遇瓶頸的指標。跳到步驟 4。 跳到步驟 4。步驟 4# sar -d interval iterations任何磁碟的 %busy 值是否大於 50？（請記住，50% 只是一個大約的原則，比較好的問法應該是它是否遠大於您系統的正常值。其他系統在正常情況下可能磁碟有 50%是忙碌的，但在某些系統上即使

4、 %busy 的值為 20 仍然表示有磁碟瓶頸。） 對這個磁碟而言，avwait 是否大於 avserv？ 大概可能是磁碟瓶頸，跳到步驟 6。 在這個裝置上似乎有 IO 瓶頸。跳到步驟 5。步驟 5系統有磁碟瓶頸。在那個瓶頸的磁碟上是什麼？原始分割區 （Raw Partition），檔案系統 - 跳到第 3 節，部份 B 調整 Disk I/O Bound 系統。Swap - 可能是記憶體瓶頸。跳到步驟 6。步驟 6# vmstat interval iterations一段時間之後 po 值是否大於 0？對於 s800 系統，（free * 4k） 是否小於 2 MB （對 s700 而言，

5、 free * 4k 小於1 MB）？（2 MB 和 1 MB 的值為概略的原則，LOTSFREE 真正的值是系統最初分頁的值，在系統開機時基於系統記憶體大小計算而得。） 假如再步驟 1 時 %idle 的值是低的，則很可能是 CPU Bound 系統。跳到第 3 節，部份 A 調整 CPU Bound 系統。如果 %idle 的值不低，那就不是 CPU、Disk I/O 或記憶體瓶頸。跳到第 4 節，其他瓶頸。 系統有記憶體瓶頸。跳到第 3 節，部份 C 調整 Memory Bound 系統。第 3 節 調整系統瓶頸下列資訊可以幫助您減少對瓶頸資源的需求或是改變瓶頸對系統的影響 （將一些較不

6、重要之程序所使用的資源分配給重要的程序使用，應該可以加快重要程序的執行速度並減慢較不重要程序的執行速度）。雖然在許多系統上產生的結果並不理想，但在某些系統上某些建議或許可以產生顯著的結果。注意: 下列建議不一定對每一種情況都有效。在某些情況下最有效的解決方法就是升級系統的硬體。也有一些情況用下列調節方式並無法減輕問題。有時候系統對於軟體的解決方法負荷過重，這種情況下硬體升級將是必要的。效能顧問可提供您更詳細且個人化的建議。A. 調整 CPU Bound 系統當系統是 CPU Bound 時第一個要考慮的是: 是否有一個特定的程序或一群程序佔用大量的CPU 資源超過 CPU 公平分享的狀態？在

7、Glance Global Process 畫面中可以檢視每個程序使用 CPU 的百分比。上面也會顯示這個資訊。ps -ef 命令會列出已執行程序清單，顯示每個程序自開始執行以來已累積使用的 CPU 時間。有一些程序比其他程序使用更大部份的 CPU，例如從一個應用程式收到即時的回應會比用三小時或更快的兩小時時間來完成備份工作來得更重要。下列列出了一些控制 CPU 使用量的方法。有關下列命令更多的資訊- 在非尖峰時間執行 Long Batch 作業。- Nice（1） 較不重要的應用程式。- Use plock（2） 來幫助重要程序。（這會引起系統上其他程序的記憶體瓶頸。- 關掉系統的統計和稽核

8、。- 考慮使用 Taskbroker 或 DCE。- 考慮使用 Process Resource Manager，一個附加價值的工作時間表。- 將正在使用主要 CPU 資源的應用程式做最佳化。然而，這個方法通常比升級系統CPU 的成本更大。- 用 NFS Diskless 用戶端來替代 Xstations （他們每台有自己的 CPU）。B. 調整 Disk I/O Bound 系統有一點要特別注意的是沒有方法可以用來辨別是真正的磁碟機制瓶頸或是匯流排控制器瓶頸。需要借助系統外部的裝置來做決定。當您做任何步驟來減輕磁碟瓶頸時，請記住這一點。在裝置上用 Glance 可看出引起高 I/O 的是哪一

9、個分割區 （Partition），最容易的是使用Logical Volume 畫面。- 如果這個瓶頸是在 Swap 分割區 （引起無法避免的記憶體瓶頸），用多個相同大小及優先順序的 Swap 區域來平衡橫跨多個 Spindle/匯流排的 I/O。- 平衡橫跨多個 Spindle/匯流排的磁碟 I/O。- 調整 （增加） Buffer Cache 的大小 （這只能幫助檔案系統）。但必需是平衡的，因為事實上很大的 Buffer Cache 將對系統效能產生負面的影響。- 如果使用線上 JFS，使用 fsadm 來調整檔案系統。- 檔案系統中有越多的空閒空間，則資料放入結構中就會有更好的尋找效率。-

10、 將一群磁碟給特定的應用程式使用，然後平衡這個橫跨這群磁碟的應用程式 I/O。- 建立檔案系統時請使用 mkfs（1m） 選項。檔案系統就會被建立為特定用途。例如，一個有許多磁柱群組 （Cylinder Group） 及 inode 的檔案系統是設計來將檔案存放於檔案系統結構之內，當有許多小檔案時這將提供更有效率的尋找時間。- 考慮使用非同步 IO （Kernel 參數 fs_async）。請注意非同步 IO 將增加系統當機時資料遺失的機率。- 考慮使用立即回報。（由 scsictl 命令控制，或 10.X 中的 Kernel 參數default_disk_ir。） 這也是一個非常危險的選項，

11、因為這也會增加系統當機時資料遺失的機率。- 將 Symbolic Link 減到最少。- 當建立一個檔案系統時，儘可能讓檔案系統的 Block 大小和檔案的大小相符合。- 假如檔案系統是在 9.X 中建立的，用 tunefs 命令將檔案系統的旋轉延遲（Rotational Delay） 調整為 0。這只對延遲時間更改後才寫入的檔案有效。在 10.X 及以後版本上的旋轉延遲預設值為 0。- 增加 ninode，如果在系統上通常使用長目錄路徑來存取檔案。然而，ninode 不能太大，inode 表格太大會對系統產生負面影響 （通常當 ninode 超過 4000 時， 就會看到系統效能開始下降了）

12、。C. 調整 Memory Bound 系統首先，先了解哪一個程序使用大量的記憶體。在 Glance 的 Global 畫面中，RSS 變數會反映出記憶體的使用量。在 ps -ef 清單中，SZ 欄位顯示記憶體的使用量。- 減少記憶體鎖定的數量。Kernel 參數 unlockable_mem 可以限制可鎖定記憶體的數量。- 殺掉不必要的視窗。（Shell Timeout 在這裡有幫助）。- 判斷哪一個程式有 Memory Leak （他們佔據的記憶體數量會越來越大）。- 調整 （減少大小） 檔案系統的 Buffer Cache。D. 調整 File System Buffer Cache已經

13、確定問題是檔案系統 I/O 瓶頸或記憶體瓶頸。在這兩種情況下，調整 Buffer Cache的大小可能可以解決問題。相對於 10.X 預設範圍為 5% 到 50% 主記憶體容量的動態Buffer Cache 而言，固定大小的 Buffer Cache 是用來測量 Buffer Cache 效力及變更效力最容易的方式。Buffer Cache 的大小是由 Kernel 參數 bufpages、nbuf、dbc_max_pct 和 dbc_min_pct 來控制。SAM Help 提供這些參數更多的資訊，而在System Administration Tasks 手冊中有如何重建 Kernel 的

14、資訊。從歷史經驗看來，HPUX 的預設 Buffer Cache 大小約為主記憶體的 10%。Buffer Cache 的目的是為了增加磁碟 IO 讀寫的速度。增加效能的方法是使用部份的主記憶體。在隔離使系統變慢的資源後，剩下的工作就是調整 Buffer Cache 的大小以達到最佳的系統回覆狀態。# sar -b interval iterations可看到 %rcache = 90 及 %wcache = 70% 這個滿意的結果。有一些系統配置（例如有原始分割區或應用程式執行隨機讀寫的系統） 將無法看到這些 Buffer Cache 的Hit Rate。目標就是要調整 Cache 使它在特

15、定系統上得到最好的效能。從一個固定的Buffer Cache 大小開始，將 Cache 調整大一點或小一點 （例如一次調整 2%）。然後測量結果: Hit Rate 是否有增加或減少，變更後記憶體的使用情形是否有變好？請記住兩件事: 如果 %rcache 和 %wcache 沒有如您少量增加或減少 Buffer Cache 的值一樣變化時，則這個調整動作雖沒有幫助也不會傷害檔案系統 I/O 的效能。另外，每個系統在不同讀寫時將達最高 Hit Rate。而有些系統將不會看到非常高的 Hit Rate。第 4 節 其他瓶頸首先，再重聲一次，系統必需安裝適當的補強程式。各種子系統的補強程式可使系統效

16、能有很大的不同。與效能問題有關的其他資源有網路、應用程式本身或系統上除了磁碟機以外的周邊設備。在 Iostat 和 Glance 中所看到的其他 I/O 瓶頸症狀皆是高 I/O 活動項目的。在 Glance Network Interface 畫面中看出高碰撞 （Collision） 數字可看出有網路瓶頸。也可用netstat 命令來診斷網路瓶頸。當然，主要的症狀是: 這個效能問題是否沒有發生在直接連線的終端機上？資料庫會佔用很大的 CPU、記憶體和磁碟 I/O。如果應用程式執行速度很慢但系統並沒有任何資源瓶頸時，則應用程式管理員通常需要檢視一些事項。應該要辨別程序是否會佔用很多 CPU 資源

17、。則需要用不同的值來執行以決定給他們更多或更少的 CPU 資源。用戶端的負載可以被分散在好幾個系統之間。如果使用原始分割區，則為了更好的記憶體/IO 平衡應用程式的 IO Cache 必需要做調整。而為了更好的磁碟 IO，應該更小心的考量記錄檔、表格和索引的放置位置。可減少程式碼中的旗號 （Semaphore）。可以對應用程式正在使用的記憶體大小做最佳化。另外，資料庫通常會用很多鎖定 （Lock），因此在本質上會使應用程式的速度變慢並可能導致 Deadlock 及 Dirty Read。應該將鎖定的使用減到最少。第 5 節 補強程式補強程式可以使系統的效能產生最大的不同。有一些不同子系統的補強程式及適當的補強程式可以安裝到系統上。有關可用補強程式的更多資訊請參考 HP IT 資源中心:有一個公用程式可以用關鍵字來搜尋補強程式，且可下載選定的補強程式。Response Center也可透過 Email 或 DAT Tape 將補強程式寄給您。關鍵字Performance Tuning