【文章內容簡介】 ),它決定動態(tài)的文件系統(tǒng)buffer cache最多可以增長到物理內存的百分之多少(如果nbuf,bufpages都設為0的話).默認是50%,絕大多數(shù)情況這個值設備太大了。Buffer cache設備太大，你更可能面臨空閑內存太低，然后被迫做page out操作再縮小buffer cache來保障其他程序的正常工作，你不會希望遇到這種情況。如果你想用動態(tài)的buffer cache, 先將dbc_max_pct 按上面的建議設一個相當?shù)闹?比如說，設成5,就是20*5%=1GB). 把dbc_min_pct設成相同的，或是更小一點的值(不會影響性能，只要你別弄得內存緊張到需要pageout) 我們在下面還有一個章節(jié)對Buffer Cache深入挖掘。，文件系統(tǒng)的數(shù)據已經不有buffer cache了，你就不用關心buffer cache的大小，而是下面講的Unified File Cache UFC的設置.NOTE: 使用大buffer cache造成性能下降的可能性現(xiàn)在基本不存在了(每一個版本都更好一些). 如果你有充足的內存想設一個大Buffer cache,來吧！整吧! Stephen見過不少客戶()設置越大的buffer cache,應用性能就越好。剛好數(shù)據庫要做兩樣事情:從文件系統(tǒng)做大量的串行讀，然后寫(也讀)到裸設備里. 這是一個正面典型。現(xiàn)在高達幾個GB的buffer cache已經很常見了。default_disk_ir這個設置讓磁盤驅動器不等到磁盤IO結束就報告(IO完成),和對每一個硬盤執(zhí)行This scsictl –m ir=1 的效果一樣。對XP這樣的有自己的緩存的大型陣列來說，這樣做沒有效果，但是對傳統(tǒng)的硬盤有。默認值是0，但建議你就設為1. 你可能說這是放TM臭屁！（黃按: 這個不是太肯定，sphincter 意為括約肌，Stephen原文為This remendation may be a ‘ on your sphincter scale,’ 專門google了一哈，有一篇小文把放屁分為十種境界，氣體通過括約肌釋放出來的過程即為放屁. 起碼字面上是一致的，sphincter scale 9/10的場景還真有些銷魂，而且我覺得Stephen說得出這種話來。），但這是從系統(tǒng)頻繁crash、數(shù)據恢復機制也不完善的年代遺留下來的觀點。據我們所知設成1沒什么壞處，不會影響數(shù)據的完整性。filecache_max and filecache_min,它們是配置動態(tài)Unified File Cache的范圍，基本上完本替代了Buffer Cache的功能。 目標還是一樣，不要造成內存緊張。你絕對要讀一下長氣的man page：man 5 filecache_max ，也瞄一眼這篇文檔后面的UFC章節(jié)。底線是:UFC默認設置到物理內存的5%50%。如果你覺得內存緊張，通常就把filecache_max調小點。，內存多就配個大的UFC,沒問題。max_thread_proc, maxuprc, maxfiles, maxfiles_lim, maxdsiz, maxssiz,maxdsiz_64, and friends有一堆參數(shù)是調整一些什么東東的最大值。過去這些參數(shù)比較重要，因為有比較多的弱智程序做些蠢事。現(xiàn)在，更可能是一些值比預期的workload所需要的低了。所以你覺得默認值太低就調高一點，或者按軟件供應商的建議調。如果你確信沒有誰會運行一些流氓程序，例如不停地申請內存直到溢出，把maxdsiz設到最大值。Maxusers被刪掉了，太好了。Doug聽Stephen說過計算核心參數(shù)的公式通常都比較弱智。(黃按，以前的版本很大參數(shù)是根據Maxusers值計算出來的)nfile同時能打開的最大文件數(shù)(不是最大能打開多少文件，是通過Open()函數(shù)同時能打開多少文件).默認值是夠用的，如果你在Glance里發(fā)現(xiàn)File Table利用率80%(System Table Report部分),或者見到“File table overflow”錯誤，就調大nfile. 方法和nflocks (max file locks)一樣. 要是配置一個大型文件服務器，你比較可能需要調大這些參數(shù)。我們發(fā)現(xiàn)大多數(shù)用戶不知道同一個文件可以有多個文件鎖定—通過一個進程或多少進程。ninode設置HFS文件系統(tǒng)的inode緩存大小。VxFS cache 通過vx_ninode調整。nkthread最大的核心線程數(shù)。大多數(shù)情況默認值夠用。如果你使用多線程的應用，就適當調高點。nproc和你期望的負載高度相關，但是大多數(shù)系統(tǒng)默認值是夠用的。如果你了解得足夠深入，就設高點。對一個只有400個進程的系統(tǒng)，不要盲目地設到30000這么高。因為這個有些副作用，比如說增加了midaemon的共享內存段(用于Glance工具來追蹤進程信息) Glance的System Tables Report 有process table的利用率統(tǒng)計，如果正常運行時利用率超過了80%,就可以考慮調高些。shmmax我們發(fā)現(xiàn)過64位的Oracle因為這個參數(shù)設得太小，不得不將SGA共享內存分散(ipcs –ma). 這樣會降低性能。如果你有足夠的物理內存，就讓數(shù)據庫申請盡量大塊的內存. 將這個參數(shù)設到最大值(除非你擔心流氓程序把共享內存占光，這種事兒也不是沒有). 默認值是1GB,對大型服務器來說有點低。swapmem_on偽交換（Pseudo swap）是用來增加可預留的虛擬內存的，它只有你沒辦法配置足夠的swap時才有用。例如,你的swap空間比物理內存要小的話。偽交換對性能是沒有影響的，除非是系統(tǒng)想申請比device swap(黃按:應該是指硬盤swap空間)更多的預留交換空間。當你要申請的全部預留交換空間超過device swap空間時，如果沒有開啟偽交換，程序就會出錯”out of memory”,否則系統(tǒng)核心就開始在物理內存中鎖定頁面。如果這種現(xiàn)象發(fā)生，在Glance里看’Used memory swap’就會快速增長。這是個麻煩。簡單的原則是：如果有足夠的device swap空間，你不用管這個參數(shù)的設置。如果你的device swap空間不夠，那就設置這個參數(shù)。%的內存做偽交換(黃按:解釋了前面的疑問，%,%了)，不能改。建議根據你的負載配置足夠的硬盤交換空間。timeslice讓這個值設為10. 如果設成1,通常會造成太多的上下文切換(context swithing), 系統(tǒng)要處理比通常多10倍的時間片中斷，還有可能會種造成鎖競爭(lock contention)。我們從來沒見過哪個生產系統(tǒng)能過把timeslice設得小于10獲得了什么好處。對它忘掉“看情況而定”這個原則吧，設為10別改! Stephen現(xiàn)在還見到有機器錯誤地設成1的。vx_ninodeJFS inode cache可能是一大塊內存。如果你的內存超過1GB,表的默認值很高(例如，8GB內存最多可以對應25萬個VxFS inode) 但是，表默認是動態(tài)的，所以沒有持續(xù)的文件訪問是不會占用內存的。你可以用vxfsstat命令來查看。如果vsfsd系統(tǒng)進程用了太多的CPU,，可以考慮給cache指定一個靜態(tài)的值。注意你不能把vx_ninode設得比nfile還小。更詳細的信息，可以在“Commonly Misconfigured HPUX Resources”白皮書里查閱JFS Inode Cache部分內容。通常的原則是，別去動它。如果你使用一臺文件服務器同時訪問大量的文件，并且有這樣的出錯信息vx_iget inode table overflow,那就把這個參數(shù)加大。 有人會說”這是動態(tài)的，我管它干嘛呢?”.你見過有人在根目錄下面做find操作吧，你知道多長時間就會把這個表撐滿嗎？，就把這個參數(shù)設到20000.你的問題是什么?好，現(xiàn)在咱們聊聊真實的生活。一個關鍵的服務器上有些(或是全部)應用很慢，沒人知道怎么回事，你—要來解決這個問題?，F(xiàn)在…你很牛，非常牛，你已經收集了一些歷史數(shù)據。而且你也很清楚系統(tǒng)正常運行的時候是什么樣子。有人經常觀察系統(tǒng)資源的利用率，像CPU、內存、網絡、核心table啥的。Performance Agent工作得很正常，24X7地收集了數(shù)據。除了本地訪問這些數(shù)據，你還可以通過Openview家族的Performance Manager、Operation Manager遠程觀察PA的數(shù)據。而且，HP Capacity Advisor可以對這些數(shù)據進行處理。不管用什么工具，重要的是理解基線，因為東西出了差錯以后你可以什么資源異常。如果你很土，非常土，或者就是命苦，你完全不知道正常時是什么樣子，那你只能胡亂劃拉：找出工具顯示出的最可能的瓶頸，希望你努力的方向是正確的。從上（系統(tǒng)級）至下看哪些資源忙再鉆下去。理解應用程序的結構,它如何使用資源是非常有幫助的。例如，你知道系統(tǒng)是一個專用的數(shù)據庫服務器，而且主要的數(shù)據庫都存放在裸設備上，那你就不用浪費時間去調文件系統(tǒng)的參數(shù)或是buffer cache還是UFC什么的，對于祼設備來說這些不相關。如果你通過Glance和PA的parm文件把應用程序的重要進程都封裝到一個包，你就可以對比相關的應用程序資源使用情況，有希望找到故障相關的這組進程。通常繁忙的服務器上有非常多的活躍進程，所以你需要深入了解性能問題來判斷哪個進程需要進一步研究。如果一個應用程序或是進程運行不了，或是運行一段時間后退出，那么你可能面臨的不是一個性能的問題，可能是某個閥值被突破了，常見的可能是設得太小的核心參數(shù)，但最可能的是應用程序的參數(shù)設定(例如Java的設置),或是交換區(qū)空間的問題。通常查詢HPUX或是應用程序的文檔會告訴你哪些參數(shù)要增大。Glance的System Tables報告也有幫助。另外，確保已經安裝了最新的patch bundle. 如果沒有出錯的部分，但是運行的就是慢，那么事情就變得有意思了！資源瓶頸對系統(tǒng)資源來說充分的使用并不是壞事，畢竟這都是花錢買的！高的資源利用率和瓶頸不能畫等號。所謂的瓶頸，現(xiàn)象是某個資源被完全占用了，而且有一系列的進程或是線程等著用這個資源。進程等待資源時運行得比正常時就會慢些。一般的瓶頸特征如下: 某個資源被使用，而且 進程或線程在等待使用這個資源從下一章節(jié)開始，我們開始對具體類型的瓶頸進行研究。當然，我們沒辦法羅列所有可能的類型，但是我們會嘗試覆蓋最常見的。討論每種類型的瓶頸的開始部分，我們會列出幾個主要的現(xiàn)象（黃按，原文用詞‘作料’），如果有必要，就再分析得詳細一點。你可以快速地掃描一下這些’作料’與你遇到的有多吻合。就像電視上常說的(那就應該是對的)，所有好菜從好作料開始！除非你是Stephen(超級牛廚),有一套自己的作料。想更好地理解瓶頸的形成，考慮這樣一個備份的例子。備份的過程包括從磁盤讀取數(shù)據和寫入到備份設備(如另一硬盤、磁帶機或是通過網絡). 整個備份過程不可能無限快，會因為某些資源受到限制。數(shù)據流中最慢的資源可能是讀取數(shù)據的硬盤(表現(xiàn)為源數(shù)據盤接近100%繁忙)，也可能是備份輸出的設備。備份還可能會受限于CPU的速度(可能在使用壓縮算法時，指示為進程占用CPU100%時間)。你可以通過為受限的資源增加速度來加速整個備份過程，但是如果備份在你期望的時間段內完成，也沒有影響到其他任何的任務，那就沒有問題!讓備份運行得更快不是最好的使用時間的方法。記住:一個硬盤(或其他的什么)100%忙不必然預示著存在瓶頸。當伴隨著長的隊列(queue),或者還有平均響應時間的增加等，這就有可能說明有問題。如果，你的備份任務在工作時間服務器開始繁忙之前還沒有結束，你可能會發(fā)現(xiàn)備份進行時很多程序慢得像老牛破車，！一個最常見的性能問題場景就是備份任務運行得太久以至于影響到了日常的業(yè)務。通常最簡單的‘優(yōu)化’就是調整哪些內容需要備份，來保證性能與數(shù)據完整性的平衡。如果開始性能分析時已經知道哪些應用程序和進程運行得比平時慢，那就看這些特定的進程在等待什么資源。有時候不像說起來這么簡單，因為UNIX對指示在等待什么資源并不是很在行。Glance 和PA(也叫Measureware)中有這樣一個概念叫Blocked States(受限狀態(tài),等待原因)。你可以在Glance中選中一個進程，進入Wait States頁面可以看到百分之多少的時間被用來等待不同的資源。不幸的是，這通常不能直接告訴你問題的所在。有一些，比如說Priority,比較明顯。如果一個進程因為在Priority受限(blocked),那就說明它在更高優(yōu)先級的進程運行時需要等待CPU時間。有些其他的原因，比如說Streams(streams IO子系統(tǒng))就麻煩一些了。如果一個進程大部分時間受阻于Streams,那可能是因為網絡瓶頸，但更可能的是，它在從Stream設備上等待某個輸入。例如shell程序會在Stream端等待終端上的輸入。Metrics（測量指標）我們關注的是性能，不是性能指標。我們需要在分析問題的時候討論不同的指標，但是我們不會具體研究指標是如何定義的，是怎么得出來的這些內容。如果你安裝了Glance,運行xglance(和gpm是一樣的),點擊Help User’s Guide ,然后點擊Performance Metrics部分，可以看到所有的定義。另外，你可以在xglance中的某一個report窗口中點擊ConfigureChoose Metrics, 列出來這部分可選擇的Metrics, 你還可以點擊右鍵調出相應的定義說明。如果你安裝是PA（measureware），在/opt/paperdocs/ovpa/C/methp*.txt是相關定義的文檔。在文本界面運行glance可以看到部分metrics, PA也是這樣。需要工具與metrics更多信息，查找下面References部分的鏈接。我們用了很多‘進程’這個詞，但是在HPUX里實際上指的是可以單獨運行的一個單元，也就是線程。一個進程是可以有多個線程的。一個有10個線程的進程可以完全消耗10個CPU(每個線程100%占用一個CPU,父進程使用’1000%’CPU – 注意process metrics不考慮CPU個數(shù)). 這和