HPUX性能分析思路Word下载.docx
《HPUX性能分析思路Word下载.docx》由会员分享，可在线阅读，更多相关《HPUX性能分析思路Word下载.docx（14页珍藏版）》请在冰豆网上搜索。
有磁盘的％busy值经常大于50吗？
对于该磁盘，是否同时存在其avwait>
avserv的现象?
（因为涉及到physicalIO和logicalIO的配置平衡，以及bufferpage/swap空间/异步读写等问题，磁盘瓶颈很难通过单一因素判断，50％只是一个大概的评估标准，要结合具体情况综合分析。
有时候，%busy仅仅为20就已经是磁盘瓶颈，而另外的我们认为磁盘工作正常的系统，％busy值很可能已达到80）。
是系统很可能存在I/O瓶颈，去到第五步
否基本上认为不存在磁盘瓶颈，去到第六步
第五步
系统存在磁盘瓶颈。
让我们来看看深层原因，
该磁盘为swap空间该磁盘瓶颈很可能是由内存瓶颈间接造成的，去到第六步来确认。
计算问题磁盘的blks/s*该磁盘不是swap空间512，分析当前的实际应用带宽，并与磁盘柜的设计值比较，作为进一步消除瓶颈的依据。
如果现实值与设计值相差太远，说明磁盘环境的拓扑/参数设置可能不合理，要做进一步分析。
第六步
执行＃vmstat[interval][iterations]
vmstat530）
1，po值经常大于0吗？
2，对于S800系统，（free*4K）<
2MB吗？
（第一个问题是关键；
第二个问题的结果仅作参考）
否结合第一步的结果分析，如果这时%idle值很低，说明是CPU瓶颈；
否则就既不是内存瓶颈，也不是CPU或磁盘瓶颈，要看看网络或应用编码方面的问题了。
是系统存在内存瓶颈。
二、HP-UX性能调优的着手点
本文的前提：
您已初步分析了性能瓶颈的原因并准备着手解决它。
下面从CPU、内存、磁盘三个方面来分别讨论性能调优的方法。
CPU调优方法：
1，升级硬件。
2，把消耗系统资源多的任务放到非高峰期运行。
3，用nice命令调整不重要的任务。
4，用plock命令保护重要的应用任务。
5，关闭accounting和auditing功能。
6，考虑使用ProcessResourceManager。
7，考虑使用Taskbroker或DCE软件。
8，优化应用系统的架构和编码。
问题描述
我如何判断系统运行性能问题的原因？
組態資訊
HP-UX
執行效能
解決方法
您可以使用下列資訊當做一個指南來幫助您判斷系統執行效能問題的原因。
但這可能無法完全診斷每一個問題並產生一個效能很好的系統。
如果需要進一步的作業，HP的效能專家可提供系統詳細的分析並產生更深入的資訊和建議。
效能的分析與諮詢是在諮詢中心的合約範圍之外。
您的諮詢中心工程師可以介紹您效能顧問來做進一步分析。
請注意除了決定系統的效能瓶頸之外，補強程式是非常重要的，並且可使系統的執行效能有非常大的不同
第一節概論
當系統的執行效能很差時表示缺乏某些資源。
如果是系統資源的問題，那麼可以歸類為CPU、記憶體或I/O瓶頸（Bottleneck）。
資源問題的發生可能不是因為系統資源的問題，可能只是效能問題，例如，當執行一個特殊的應用程式或只是透過網路來存取系統。
這份文件將幫助您判斷您是否有系統資源瓶頸並闡述一些可以解除瓶頸的基本事項。
若要做精確的診斷，則必需在系統效能良好的時候取得一些比較的基準資料。
請注意，在進入效能瓶頸問題之前，確定系統有安裝所有效能相關的補強程式是非常非常重要的。
一般來說，當發生系統瓶頸時只有兩種解決方法:
減少有瓶頸資源的需求或增加可用資源的數量。
然而請記住，是否增加可用資源的數量並不能使得效能有很大的改善，而反而是引起系統增加對其他資源的需求。
例如，在極度依賴CPU運算的系統上新增一顆處理器將可允許CPU執行更多的程序，但試著處理額外的程序付載時也可能導致記憶體或IO的瓶頸。
第一步是開始找尋可能的CPU瓶頸。
請特別注意CPU瓶頸和100%CPU使用率是不一樣的。
然後再著手尋找磁碟和記憶體的瓶頸。
當排除效能問題時必需記得一些重要的事項。
在一個系統上可能同時有多個瓶頸，一個或多個瓶頸可能是由另一個所引起的。
且為了改善系統效能而做任何變更時，同一時間點只做一個變更是非常重要的。
如果這個變更無法解決問題，請先將它變更回去再試其他項目。
如果有幫助但並非完全解決問題，且先停止並收集新資料，再開始診斷下一個問題。
有時候當系統上有好幾個瓶頸時，可能有一個瓶頸會減輕，但可能並不是真正拖累系統的瓶頸。
例如，因為分頁活動增加所以記憶體瓶頸可能誤認為CPU或磁碟瓶頸。
第二節效能評估
A.BufferCache
一個最普遍的問題是週期性的系統暫停（1或2秒，或更久，大約每30秒）。
在這種情況下，原因通常是一個大的BufferCache的DirtyPage必需由同步程序（SyncerProcess）每30秒清空一次。
在10.X預設下，BufferCache是動態的並且可以擴充到主記憶體的50%。
在系統的經驗上，這些系統暫停、將BufferCache設定為較小值、或許以10%的記憶體啟動並將BufferCache調整為第三部份所敘述的，可能可以解決這個效能問題。
B.CPU、磁碟、記憶體及網路瓶頸的症狀
對於下列敘述的症狀，提供一些用來檢視每個症狀的建議命令。
有關命令更多的資訊及其結果請參考個別命令的ManPage，而Glance中顯示的GlanceHelp畫面對於特定欄位涵義的敘述是非常有用的。
要非常注意的是我們無法完全依賴一種工具。
必需結合各種工具才能獲得精確的系統效能狀況。
再次提醒，真正可以用來精確測量的是:
值是好是壞必需是與系統在運作良好的情況下做比較。
CPU瓶頸
ZeropercentidleCPUtime（sar-u,top）。
Withzeropercentidle,highpercentuserCPUtimecomparedto
systemCPUtime（sar-u,top）。
Largerunqueuesizesustainedovertime（vmstat530,uptime）。
Manyprocessesblockedonpriority（Glance）。
Slowresponsetime。
HighpercentsystemCPUtime（sar-u,top）。
磁碟瓶頸
Highdiskutilization（sar-d,iostat,glance）。
Largediskqueuelength（sar-d,iostat,glance）。
High%wio（sar-u）。
Lowbuffercachehitrates（sar-b）。
LargerunqueuewithidleCPU（vmstat530）。
記憶體瓶頸
Highsustainedpage_out_rates（paginginisnormal）（vmstat530）。
Smallnumberoffreeandactivevirtualmemorypages（vmstat530）。
Highdiskactivityonswapdevices（sar-d,glance,iostat）。
Outofmemoryerrors。
CPUtimegiventovhand（andswapperat9.X）（ps-ef,top,glance）。
ExcessiveCPUtimegiventosystemversususerprocesses。
C.診斷CPU、記憶體或磁碟瓶頸的流程圖
從步驟1開始查看CPU的使用情形並且遵循這些診斷CPU、記憶體或磁碟瓶頸的指令。
由下列各個步驟來觀察從系統執行效能不佳時所收集到的資料，持續一段時間以了解它的趨勢變化。
再次提醒，精確的診斷必需將這些資料與系統在運作良好情況下的資料做比較。
步驟1
#sar-u[interval][iterations]
（example:
sar-u530）
%idle的值低嗎？
這是CPU沒有執行程序的時間百分比。
持續一段時間%idle的值為零則可能是CPU瓶頸的第一個指標。
No->
系統非CPUBound。
跳到步驟3。
Yes->
系統可能是CPU、記憶體或I/OBound。
跳到步驟2。
步驟2
%usr的值高嗎？
大部分系統正常運作的情況是80%的CPU時間花在使用者時間，
20%則花在系統時間。
其他系統正常則使用多於或少於80%的使用者時間。
系統可能有CPU、記憶體或I/O瓶頸。
由於使用者程序，系統像是有CPU瓶頸。
跳到第3節，部份A調整系統的CPU瓶頸。
步驟3
%wio的值是否大於15？
請先記住。
這可能是磁碟或磁帶遭遇瓶頸的指標。
跳到步驟4。
跳到步驟4。
步驟4
#sar-d[interval][iterations]
任何磁碟的%busy值是否大於50？
（請記住，50%只是一個大約的原則，比較好的問法應該是它是否遠大於您系統的正常值。
其他系統在正常情況下可能磁碟有50%是忙碌的，但在某些系統上即使%busy的值為20仍然表示有磁碟瓶頸。
）對這個磁碟而言，avwait是否大於avserv？
大概可能是磁碟瓶頸，跳到步驟6。
在這個裝置上似乎有IO瓶頸。
跳到步驟5。
步驟5
系統有磁碟瓶頸。
在那個瓶頸的磁碟上是什麼？
原始分割區（RawPartition），
檔案系統->
跳到第3節，部份B調整DiskI/OBound系統。
Swap->
可能是記憶體瓶頸。
跳到步驟6。
步驟6
#vmstat[interval][iterations]
一段時間之後po值是否大於0？
對於s800系統，（free*4k）是否小於2MB（對s700而言，free*4k小於1MB）？
（2MB和1MB的值為概略的原則，LOTSFREE真正的值是系統最初分頁的值，在系統開機時基於系統記憶體大小計算而得。
）
假如再步驟1時%idle的值是低的，則很可能是CPUBound系統。
跳到第3節，部份A調整CPUBound系統。
如果%idle的值不低，
那就不是CPU、DiskI/O或記憶體瓶頸。
跳到第4節，其他瓶頸。
系統有記憶體瓶頸。
跳到第3節，部份C調整MemoryBound系統。
第3節調整系統瓶頸
下列資訊可以幫助您減少對瓶頸資源的需求或是改變瓶頸對系統的影響（將一些較不重要之程序所使用的資源分配給重要的程序使用，應該可以加快重要程序的執行速度並減慢較不重要程序的執行速度）。
雖然在許多系統上產生的結果並不理想，但在某些系統上某些建議或許可以產生顯著的結果。
注意:
下列建議不一定對每一種情況都有效。
在某些情況下最有效的解決方法就是升級系統的硬體。
也有一些情況用下列調節方式並無法減輕問題。
有時候系統對於軟體的解決方法負荷過重，這種情況下硬體升級將是必要的。
效能顧問可提供您更詳細且個人化的建議。
A.調整CPUBound系統
當系統是CPUBound時第一個要考慮的是:
是否有一個特定的程序或一群程序佔用大量的CPU資源超過CPU公平分享的狀態？
在GlanceGlobalProcess畫面中可以檢視每個程序使用CPU的百分比。
上面也會顯示這個資訊。
ps-ef命令會列出已執行程序清單，顯示每個程序自開始執行以來已累積使用的CPU時間。
有一些程序比其他程序使用更大部份的CPU，例如從一個應用程式收到即時的回應會比用三小時或更快的兩小時時間來完成備份工作來得更重要。
下列列出了一些控制CPU使用量的方法。
有關下列命令更多的資訊
-在非尖峰時間執行LongBatch作業。
-Nice
（1）較不重要的應用程式。
-Useplock
（2）來幫助重要程序。
（這會引起系統上其他程序的記憶體瓶頸。
-關掉系統的統計和稽核。
-考慮使用Taskbroker或DCE。
-考慮使用ProcessResourceManager，一個附加價值的工作時間表。
-將正在使用主要CPU資源的應用程式做最佳化。
然而，這個方法通常比升級系統CPU的成本更大。
-用NFSDiskless用戶端來替代Xstations（他們每台有自己的CPU）。
B.調整DiskI/OBound系統
有一點要特別注意的是沒有方法可以用來辨別是真正的磁碟機制瓶頸或是匯流排控制器瓶頸。
需要借助系統外部的裝置來做決定。
當您做任何步驟來減輕磁碟瓶頸時，請記住這一點。
在裝置上用Glance可看出引起高I/O的是哪一個分割區（Partition），最容易的是使用LogicalVolume畫面。
-如果這個瓶頸是在Swap分割區（引起無法避免的記憶體瓶頸），用多個相同大小及優先順序的Swap區域來平衡橫跨多個Spindle/匯流排的I/O。
-平衡橫跨多個Spindle/匯流排的磁碟I/O。
-調整（增加）BufferCache的大小（這只能幫助檔案系統）。
但必需是平衡的，因為事實上很大的BufferCache將對系統效能產生負面的影響。
-如果使用線上JFS，使用fsadm來調整檔案系統。
-檔案系統中有越多的空閒空間，則資料放入結構中就會有更好的尋找效率。
-將一群磁碟給特定的應用程式使用，然後平衡這個橫跨這群磁碟的應用程式I/O。
-建立檔案系統時請使用mkfs（1m）選項。
檔案系統就會被建立為特定用途。
例如，一個有許多磁柱群組（CylinderGroup）及inode的檔案系統是設計來將檔案存放於檔案系統結構之內，當有許多小檔案時這將提供更有效率的尋找時間。
-考慮使用非同步IO（Kernel參數fs_async）。
請注意非同步IO將增加系統當機時資料遺失的機率。
-考慮使用立即回報。
（由scsictl命令控制，或10.X中的Kernel參數
default_disk_ir。
）這也是一個非常危險的選項，因為這也會增加系統當機時資料遺失的機率。
-將SymbolicLink減到最少。
-當建立一個檔案系統時，儘可能讓檔案系統的Block大小和檔案的大小相符合。
-假如檔案系統是在9.X中建立的，用tunefs命令將檔案系統的旋轉延遲
（RotationalDelay）調整為0。
這只對延遲時間更改後才寫入的檔案有效。
在10.X及以後版本上的旋轉延遲預設值為0。
-增加ninode，如果在系統上通常使用長目錄路徑來存取檔案。
然而，ninode不能太大，inode表格太大會對系統產生負面影響（通常當ninode超過4000時，就會看到系統效能開始下降了）。
C.調整MemoryBound系統
首先，先了解哪一個程序使用大量的記憶體。
在Glance的Global畫面中，RSS變數會反映出記憶體的使用量。
在ps-ef清單中，SZ欄位顯示記憶體的使用量。
-減少記憶體鎖定的數量。
Kernel參數unlockable_mem可以限制可鎖定記憶體的數量。
-殺掉不必要的視窗。
（ShellTimeout在這裡有幫助）。
-判斷哪一個程式有MemoryLeak（他們佔據的記憶體數量會越來越大）。
-調整（減少大小）檔案系統的BufferCache。
D.調整FileSystemBufferCache
已經確定問題是檔案系統I/O瓶頸或記憶體瓶頸。
在這兩種情況下，調整BufferCache的大小可能可以解決問題。
相對於10.X預設範圍為5%到50%主記憶體容量的動態BufferCache而言，固定大小的BufferCache是用來測量BufferCache效力及變更效力最容易的方式。
BufferCache的大小是由Kernel參數bufpages、nbuf、dbc_max_pct和dbc_min_pct來控制。
SAMHelp提供這些參數更多的資訊，而在SystemAdministrationTasks手冊中有如何重建Kernel的資訊。
從歷史經驗看來，HPUX的預設BufferCache大小約為主記憶體的10%。
BufferCache的目的是為了增加磁碟IO讀寫的速度。
增加效能的方法是使用部份的主記憶體。
在隔離使系統變慢的資源後，剩下的工作就是調整BufferCache的大小以達到最佳的系統回覆狀態。
#sar-b[interval][iterations]
可看到%rcache>
=90及%wcache>
=70%這個滿意的結果。
有一些系統配置（例如有原始分割區或應用程式執行隨機讀寫的系統）將無法看到這些BufferCache的HitRate。
目標就是要調整Cache使它在特定系統上得到最好的效能。
從一個固定的BufferCache大小開始，將Cache調整大一點或小一點（例如一次調整2%）。
然後測量結果:
HitRate是否有增加或減少，變更後記憶體的使用情形是否有變好？
請記住兩件事:
如果%rcache和%wcache沒有如您少量增加或減少BufferCache的值一樣變化時，則這個調整動作雖沒有幫助也不會傷害檔案系統I/O的效能。
另外，每個系統在不同讀寫時將達最高HitRate。
而有些系統將不會看到非常高的HitRate。
第4節其他瓶頸
首先，再重聲一次，系統必需安裝適當的補強程式。
各種子系統的補強程式可使系統效能有很大的不同。
與效能問題有關的其他資源有網路、應用程式本身或系統上除了磁碟機以外的周邊設備。
在Iostat和Glance中所看到的其他I/O瓶頸症狀皆是高I/O活動項目的。
在GlanceNetworkInterface畫面中看出高碰撞（Collision）數字可看出有網路瓶頸。
也可用netstat命令來診斷網路瓶頸。
當然，主要的症狀是:
這個效能問題是否沒有發生在直接連線的終端機上？
資料庫會佔用很大的CPU、記憶體和磁碟I/O。
如果應用程式執行速度很慢但系統並沒有任何資源瓶頸時，則應用程式管理員通常需要檢視一些事項。
應該要辨別程序是否會佔用很多CPU資源。
則需要用不同的值來執行以決定給他們更多或更少的CPU資源。
用戶端的負載可以被分散在好幾個系統之間。
如果使用原始分割區，則為了更好的記憶體/IO平衡應用程式的IOCache必需要做調整。
而為了更好的磁碟IO，應該更小心的考量記錄檔、表格和索引的放置位置。
可減少程式碼中的旗號（Semaphore）。
可以對應用程式正在使用的記憶體大小做最佳化。
另外，資料庫通常會用很多鎖定（Lock），因此在本質上會使應用
程式的速度變慢並可能導致Deadlock及DirtyRead。
應該將鎖定的使用減到最少。
第5節補強程式
補強程式可以使系統的效能產生最大的不同。
有一些不同子系統的補強程式及適當的補強程式可以安裝到系統上。
有關可用補強程式的更多資訊請參考HPIT資源中心:
有一個公用程式可以用關鍵字來搜尋補強程式，且可下載選定的補強程式。
ResponseCenter也可透過Email或DATTape將補強程式寄給您。
關鍵字
PerformanceTuning
升级会员 