【正文】 最主要的目標是降低內(nèi)存的使用率避免Paging out.如果你的應用程序可以從很大的cache獲益，你也有足夠的空閑內(nèi)存，那就配大些。如果根據(jù)上面的的現(xiàn)象，你懷疑buffer cache可能太大了，而且你經(jīng)?？吹絻?nèi)存利用率超過90%,而且你的Buffer Cache比1GB還大，那就把它改小點，改成比它現(xiàn)在的一半多點或是1GB. 改完了以后，再觀察一下命中率。就是要記住你如果增加了物理內(nèi)存，buffer cache的大小也會跟著增加。 cache,參考上面的核心參數(shù)部分關于bufpages和dbc_max_pct的內(nèi)容。在實際環(huán)境中，我們見到更多的情況是buffer cache設得太大了。Buffer Cache Bottlenecks現(xiàn)象: 在至少一個硬盤上有中等的使用率 (GBL_DISK_UTIL_PEAK orhighest BYDSK_UTIL 25), 并且 持續(xù)較低的Buffer Cache讀命中率 (GBL_MEM_CACHE_HIT_PCT 90%). 進程或線程受阻于Cache (PROC_STOP_REASON = CACHE).，如果有足夠內(nèi)存，你可以考慮把file system的buffer cache調(diào)大，尤其是處理NFS,ftp,Web,或其他文件服務的情況，前提是不要因為內(nèi)存壓力。這絕對會降低小的寫操作、隨機寫操作和直接IO的速度。如果你對buffer或是file cache做個小的寫操作，而且buffer或是page還沒有在cache里，或是做裸設備IO。無論是通過buffer cache,file cache還是直接訪問都有可能發(fā)生，它有可能會造成性能下降。不幸的是，如果你沒有源代碼，那你對編程方面的問題也沒什么好的處理辦法。要深入分析，可以找做大量IO操作，并且用很多System CPU的程序。注意’濫用’IO的程序 – 產(chǎn)生海量的文件或是做大量的打開、關閉文件操作。如果出現(xiàn)跨越邊界的情況會造成一個IO被分成幾個更小的IO，這些情況有:文件系統(tǒng)計塊大小，緩沖鏈(buffer chain)，文件塊(file extent)和LVM LTG邊界。IO越小，響應時間越短，反之亦然。通常來說增大隊列深度可能會提升并行處理能力，代價是有可能使硬件超負荷。vxtunefs可能會有幫助，對于建議的VxFS參數(shù)設置，參考上面的系統(tǒng)設置章節(jié)。不同的應用程序有不同的控制方式。嘗試著把忙的文件系統(tǒng)或是邏輯卷分布到不同的IO卡與磁盤上來獲取最大的吞吐量。你可能需要從磁盤陣列的供應商得到這樣的工具。對于所有性能分析工具都存在的問題是磁盤內(nèi)部的硬件對它們是不透明的。你還可以看到邏輯IO與物理IO的對照，物理IO還可以細分為文件系統(tǒng)、裸設備、虛擬內(nèi)存(paging)和系統(tǒng)級(inode操作)等等。也可以看看上面討論交換區(qū)設置的部分。 注意:你會經(jīng)?？吹教囟ǖ牡刂菲骄憫獣r間(average service time)的值非常高，但是跟蹤下去你發(fā)現(xiàn)，這些設備在做極少甚至沒有IO! 在做海量IO操作的設備可能有著非常漂亮的響應時間數(shù)據(jù)。很多舊時的性能磚家喜歡用磁盤的平均響應時間(Average Service Time)來做瓶頸的指標。另一個有用的全局metric是GBL_DISK_SUBSYSTEM_QUEUE,顯示平均有多少個進程受阻于IO等待。注意PA的metric GBL_DISK_UTIL_PEAK不是一個平均值，也不是只針對一個硬盤。通過BYDSK_UTIL metric過濾數(shù)據(jù)，觀察利用率發(fā)展的趨勢，然后通過BYDSK_REQUEST_QUEUE觀察隊列情況。 ，可以以IO卡(HBA)為單位分析。要找出熱點，通過性能分析工具顯示不同磁盤設備的利用率。理想的情況是把磁盤IO分布在盡可能多的IO卡、LUN和物理硬盤上來避免任一特定IO路徑上的瓶頸。可悲的是，這不總是(其實是從來不是)可能的。我們不鼓勵用文件系統(tǒng)交換區(qū)，但是你如果確認它不會被用到（優(yōu)先級設成比其他交換區(qū)更高），那也成。保證這一點以后，你可以通過幾種方式來保證有足夠的可預留的空間(watch GBL_SWAP_SPACE_UTIL) . 因為不實際使用的交換空間沒有IO發(fā)生，你可以用些慢的空閑硬盤。Stephen的話是”保證瓶頸不在IO卡上” 。確保它們的大小一致，在不同的物理硬盤上，有一樣的交換優(yōu)先級，比其他的交換區(qū)小些的一個數(shù)字。實際使用多少交換空間是完全不同的一件事，系統(tǒng)通常預留比實際會使用多得多的交換空間。Swap sizing （交換區(qū)大?。┙粨Q區(qū)的配置有兩點很重要。沒有虛擬內(nèi)存IO的產(chǎn)生，這只是OS在內(nèi)存緊張時先發(fā)制人采取的一個措施。這不是一個’真正的’內(nèi)存瓶頸。這個有點深了，只有你的應用程序供應商建議時才用。要注意報告”out of memory”錯誤的程序，因為通常這可能是沒有足夠了的交換空間或是遇到配置的極限值了(查看上面關于系統(tǒng)設置核心參數(shù)部分的內(nèi)容)關于內(nèi)存還有一個有意思的狀況是使用很多共享內(nèi)存的32位程序可以通過配置內(nèi)存窗口（memory window）獲益(對于需要運行幾個實例的，比如說32位的Oracle,Informix,SAP等. 大的頁面大小對某些程序很有效，保證內(nèi)存的本地訪問，避免TLB超負荷。你還是面臨內(nèi)存緊張的壓力，那唯一的解決辦法就是再買些內(nèi)存。在統(tǒng)計數(shù)據(jù)中也面臨相似的疑惑，所以有時被報告為free的，有時被報告為已用的。有人可能說，UFC保留‘舊’的頁面滿足再次訪問的需要，這部分內(nèi)存當然是free的。想得到相對最好用的metrics，找Glance/PA的最新的補丁和相關的核心補丁。注意(在2009版更新), 內(nèi)存相關的metrics是‘懂了’的雷區(qū)。過大的UFC也類似。當然，修正問題程序是更好的解決方案。內(nèi)存泄露的現(xiàn)象通常是DATA region隨著時間的推移緩慢增長，但是也可能通過未做unmap操作的內(nèi)存映射文件(MEMMAP/Priv region持續(xù)增長).總得來說，如果有內(nèi)存泄露，你會發(fā)現(xiàn)GBL_SWAP_SPACE_UTIL 增長。如果你的應用程序沒能較好地通過parm文件組織起來，可以用Glance然后以PROC_MEM_VIRT 排序，看使用最多內(nèi)存的進程。如果你的PA parm文件組織得好，間中比較一下虛擬內(nèi)存的使用(APP_MEM_VIRT) 對檢查是否存在內(nèi)存泄露是很有幫助的。如果內(nèi)存利用率90%,那沒事偷著樂吧。UFC在本文后面單獨成一章。如果內(nèi)存利用率小于95%,有一些pageout發(fā)生，通常是因為內(nèi)存映射文件的寫操作。當內(nèi)存利用率高時，關注pageout,因為能常這時內(nèi)存瓶頸的指示(也不總是，!)。但這不是說它必須被交換出去!我們可以就這個專題講很多，但不是在這里對你講。當HPUX需要在物理內(nèi)存中整理出一些空間，或是當一個內(nèi)存映射文件(memorymapped file)被posted,結果是一個’page out’操作，過去被稱做交換操作(swap),把物理內(nèi)存中一整套相關的信息寫到交換磁盤上，現(xiàn)在叫去激活(deactivations),所有屬于相關進程的內(nèi)存頁都被標記，交換出去。通常通過增加每個進程可以占用CPU的時間段，可以降低任務調(diào)度的超負荷。信號量(Semaphore)競爭是一個常見原因，因為進程總是總是受阻于信號量等待。 metric并排序。用xglance來跟蹤是哪些進程在做很多的fork操作不難。我們也遇到過一些不安裝代理程序的系統(tǒng)監(jiān)控程序不停地遠程登錄運行一些命令。換個講法，非常頻繁地有新的進程序產(chǎn)生(可以假定也有大量的進程結束). 頻繁的登錄操作是fork操作的一個主要源頭，因為shell的登錄profile經(jīng)常運行一些生命周期很短的進程。當系統(tǒng)頻繁地做上下文切換時，因為切換操作不可避免地帶來一些開銷，有用的進程可能會被拖慢。這個就復雜嘍，一瓶啤酒還不夠Stephen講的。（黃按:晚點我貼一個tusc的文件上來）.我們得說有些應用程序被設計成生成無窮多的系統(tǒng)調(diào)用，但是沒有太多的辦法，尤其是對第三方開發(fā)的程序。如果程序不做系統(tǒng)調(diào)用，那它就不會被kernel拖慢下來，遺憾的是不總是能做到。通常來講，這是OK的因為從一個系統(tǒng)管理員的角度你對這也沒什么辦法。這種情況會造成很長時間的系統(tǒng)調(diào)用。在繁忙的大型系統(tǒng)計上，系統(tǒng)模式CPU瓶頸可以是核心資源的競爭，比如說數(shù)據(jù)結構一次只能由一個CPU訪問。這樣的操作帶來的副作用就是產(chǎn)生很多核心系統(tǒng)調(diào)用來跟蹤，從而使midaemon(Glance和PA使用)進程使用大量的CPU時間。另一個常見的原因是過多的stat類型文件系統(tǒng)類的系統(tǒng)調(diào)用（find命令就容易造成類似的調(diào)用，shell配置了過長的PATH變量也有可能）。當你了解了是哪些進程造成了瓶頸，它們在執(zhí)行什么操作，剩下的難點就是判斷為啥了，我們留給用戶作為練習！常見的編程錯誤就像重復的gettimeofday(), sched_yield(),或是 select() 在xglance的Process List報告中，可以選擇PROC_CPU_SYS_MODE_UTIL,，點擊Process System Call report,等一段時間后（等幾個glance更新數(shù)據(jù)的時間間隔）,就可以看到進程正在使用的系統(tǒng)調(diào)用。選擇 ReportsSystem InfoSystem Calls, 在界面中以syscall rate排序. 最經(jīng)常被調(diào)用的system call會排在最前面。如果這問題正在發(fā)生，那就用Glance再進入一點看。查看性能有問題時段哪個進程系統(tǒng)調(diào)用最高(highest PROC_CPU_SYSCALL_UTIL) 如果問題出現(xiàn)時你能使用Glance是最好的，你可以去買張彩票跳到下一段。換句話說，如果你不是要處理海量的IO，而且你觀察到很高的中斷處理量，不用擔心綁定CPU的數(shù)量是否足夠。有人和我們聊過vPars中關于綁定或是非綁定CPU（bound,unbound）的問題,只有綁定的CPU處理IO中斷。先研究IO相關的問題。首先，檢查是否大部分消耗在上下文切換(context switching). 這本身就是一個專題，如果是的話直接跳到下面的上下文切換瓶頸的相關部分。另一個方式是應用程序的優(yōu)化，如果有源代碼的話有很多編程工具可以用。最簡單的解決CPU瓶頸的方法是買更強的CPU處理能力。如果你設置了SCHED_NOAGE,它就告訴核心不要降低一個進程或是線程的優(yōu)先級。這個有點復雜，Stephen可以就這個開一個兩天的研討會。有很多調(diào)度任務的技巧，包括POSIX scheduler, 盡管這不常用。你在Glance中選中一個進程也可以調(diào)用。系統(tǒng)不斷變化，有時候就是需要找到最合用的工具。 HP PRM工具(Process Resource Manager)和gWLM(Global Work Load Manager)可以檢查每個應用對CPU的使用。如果是‘錯’的應用程序占用了全部CPU時間，表現(xiàn)為重要的進程總是因Priority被Block。在Glance中，你可以選中一個進程進一步獲取詳細信息。User CPU Bottlenecks （用戶模式CPU瓶頸）問題現(xiàn)象: 如上面所述的CPU瓶頸的現(xiàn)象,并且 大部分CPU時間花在用戶代碼上 (GBL_CPU_USER_MODE_UTIL 50%).如果你的系統(tǒng)大部分時間在執(zhí)行核心以外的代碼，通常是件好事。我們的法則多年來已經(jīng)被很多管理員驗證過。 它的效果和運行top或是uptime命令中的Load Average metric(平均負載)基本上是一樣的。Stephen比喜歡用Run Queue更喜歡這個。Stephen喜歡把這些稱為‘犯規(guī)’程序。找出為什么CPU瓶頸發(fā)生有時不那么容易。CPU Bottlenecks (CPU瓶頸)CPU瓶頸現(xiàn)象的作料(故障現(xiàn)象):持續(xù)的高CPU占用率 (GBL_CPU_TOTAL_UTIL 90%) 運行隊列值偏大（Significant Run Queue,即指平均負載) 或是進程持續(xù)因為Priority受阻（ blocked on Priority） (GBL_RUN_QUEUE 3 or GBL_PRI_QUEUE 3). 重要進程經(jīng)常顯示為等待CPU （ blocked on Priority ）(PROC_STOP_REASON = PRI).判斷是否存在CPU瓶頸很簡單。就像下面在內(nèi)存瓶頸部分的例子。任何性能工具提供給你的不管精確到多少位的數(shù)字基本上都是有偏差的！這里面的原因涉及到采樣、標準化、壓縮、同步等多方面。一個有10個線程的進程可以完全消耗10個CPU(每個線程100%占用一個CPU,父進程使用’1000%’CPU – 注意process metrics不考慮CPU個數(shù)). 這和10個單線程的進程，每個100%占用一個 CPU是類似的。我們用了很多‘進程’這個詞，但是在HPUX里實際上指的是可以單獨運行的一個單元，也就是線程。在文本界面運行glance可以看到部分metrics, PA也是這樣。另外，你可以在xglance中的某一個report窗口中點擊ConfigureChoose Metrics, 列出來這部分可選擇的Metrics, 你還可以點擊右鍵調(diào)出相應的定義說明。我們需要在分析問題的時候討論不同的指標，但是我們不會具體研究指標是如何定義的，是怎么得出來的這些內(nèi)容。例如shell程序會在Stream端等待終端上的輸入。有些其他的原因，比如說Streams(streams IO子系統(tǒng))就麻煩一些了。有一些，比如說Priority,比較明顯。你可以在Glance中選中一個進程，進入Wait States頁面可以看到百分之多少的時間被用來等待不同的資源。有時候不像說起來這么簡單，因為UNIX對指示在等待什么資源并不是很在行。如果，你的備份任務在工作時間服務器開始繁忙之前還沒有結束，你可能會發(fā)現(xiàn)備份進行時很多程序慢得像老牛破車，！一個最常見的性能問題場景就是備份任務運行得太久以至于