【正文】 造成內(nèi)存瓶頸的原因是內(nèi)存泄露，這發(fā)生在程序申請了虛擬內(nèi)存又忘了釋放它。如果你的PA parm文件組織得好，間中比較一下虛擬內(nèi)存的使用(APP_MEM_VIRT) 對檢查是否存在內(nèi)存泄露是很有幫助的。用Performance Manager,你可以就APP_MEM_VIRT metric 用圖形方式顯示出來。如果你的應(yīng)用程序沒能較好地通過parm文件組織起來，可以用Glance然后以PROC_MEM_VIRT 排序，看使用最多內(nèi)存的進程。在Glance中，選中一個使用虛擬內(nèi)存多的（with a large virtual set size）進程，在Process Memory Regions 報告部分可以看到進程在每一region使用內(nèi)存的詳細信息。內(nèi)存泄露的現(xiàn)象通常是DATA region隨著時間的推移緩慢增長，但是也可能通過未做unmap操作的內(nèi)存映射文件(MEMMAP/Priv region持續(xù)增長).總得來說，如果有內(nèi)存泄露，你會發(fā)現(xiàn)GBL_SWAP_SPACE_UTIL 增長。重起應(yīng)用程序或是重起系統(tǒng)是一個暫時的解決辦法。當(dāng)然，修正問題程序是更好的解決方案。o，一個常見的造成內(nèi)存瓶頸的原因是文件系統(tǒng)計緩存設(shè)得過大。，過大的UFC也類似。如果有內(nèi)存瓶頸，你的buffer Cache（）或是UFC（）大于1GB,可以考慮縮小點。注意(在2009版更新), 內(nèi)存相關(guān)的metrics是‘懂了’的雷區(qū)。不進行非常深入的研究，就可以信任的metric是總的內(nèi)存利用率(GBL_MEM_UTIL and GBL_MEM_FREE), 最不可信的部分是用戶、系統(tǒng)、UFC部分的利用率(GBL_MEM_USER, GBL_MEM_SYS, GBL_MEM_FILE_PAGE_CACHE), 還有虛擬內(nèi)存(GBL_MEM_VIRT). 這是因為底層的一些復(fù)雜結(jié)構(gòu)，在包括HPUX的所有操作系統(tǒng)都做得不太好。想得到相對最好用的metrics，找Glance/PA的最新的補丁和相關(guān)的核心補丁。還需要注意的是，file page cache是否被統(tǒng)計為使用的內(nèi)存。有人可能說，UFC保留‘舊’的頁面滿足再次訪問的需要，這部分內(nèi)存當(dāng)然是free的。另一些人可能認為UFC里的內(nèi)容都是準(zhǔn)備回寫到硬盤上的數(shù)據(jù)，所以是使用的，而不是free的。在統(tǒng)計數(shù)據(jù)中也面臨相似的疑惑，所以有時被報告為free的，有時被報告為已用的?？傊?，對照以前用老式的buffer cache的情況，現(xiàn)在的情況不是太明確，提醒一下。如果沒有內(nèi)存泄露問題，buffer cache或是UFC配得也合理。你還是面臨內(nèi)存緊張的壓力，那唯一的解決辦法就是再買些內(nèi)存。大部分數(shù)據(jù)庫都申請超大的共享內(nèi)存段，你需要確保有足夠的物理內(nèi)存來避免它發(fā)生paging操作。要注意報告”out of memory”錯誤的程序，因為通常這可能是沒有足夠了的交換空間或是遇到配置的極限值了(查看上面關(guān)于系統(tǒng)設(shè)置核心參數(shù)部分的內(nèi)容)關(guān)于內(nèi)存還有一個有意思的狀況是使用很多共享內(nèi)存的32位程序可以通過配置內(nèi)存窗口（memory window）獲益(對于需要運行幾個實例的，比如說32位的Oracle,Informix,SAP等. 大的頁面大小對某些程序很有效，保證內(nèi)存的本地訪問，避免TLB超負荷。Java以內(nèi)存映射文件自己管理JVM中的虛擬內(nèi)存，這個很復(fù)雜，關(guān)聯(lián)到各種各樣的Java參數(shù)。這個有點深了，只有你的應(yīng)用程序供應(yīng)商建議時才用。yOh yeah,如果這些還不夠叫你頭疼，Stephen有個很喜歡的話題是’假的去激活’(‘false deactivations’). 有時想HPUX會置于一個有趣的境地，當(dāng)內(nèi)存接近用完但是還沒到引起pageout的時候你有時會看到去激活. 這很少見，但是你如果看到系統(tǒng)中沒有paging操作但是有去激活發(fā)生，那就可能是這種情況了。這不是一個’真正的’內(nèi)存瓶頸。被去激活的進程沒有被交換出去就又被激活了。沒有虛擬內(nèi)存IO的產(chǎn)生，這只是OS在內(nèi)存緊張時先發(fā)制人采取的一個措施。這情況只是有點討厭而已，因為不能直接以去激活操作作為內(nèi)存瓶頸的標(biāo)志。Swap sizing （交換區(qū)大小）交換區(qū)的配置有兩點很重要。你要確保至少有足夠的可申請預(yù)留的空間。實際使用多少交換空間是完全不同的一件事，系統(tǒng)通常預(yù)留比實際會使用多得多的交換空間。交換區(qū)只有在swap發(fā)生時才被用到，只要虛擬內(nèi)存申請發(fā)生，交換區(qū)就會被預(yù)留(reserved).在磁盤setup部分提到的那樣，你最少配置兩個交換空間來保證交換真正發(fā)生時能比較快。確保它們的大小一致，在不同的物理硬盤上，有一樣的交換優(yōu)先級，比其他的交換區(qū)小些的一個數(shù)字。如果可能，將硬盤連接在不同的IO控制器上。Stephen的話是”保證瓶頸不在IO卡上” 。 用Glance的Swap Space報告或是swapinfo確認系統(tǒng)的大部分或是全部真正使用的交換區(qū)在這樣的設(shè)備上。保證這一點以后，你可以通過幾種方式來保證有足夠的可預(yù)留的空間(watch GBL_SWAP_SPACE_UTIL) . 因為不實際使用的交換空間沒有IO發(fā)生，你可以用些慢的空閑硬盤。如果硬盤交換空間不足，一定要的打開Pseudo Swap。我們不鼓勵用文件系統(tǒng)交換區(qū)，但是你如果確認它不會被用到（優(yōu)先級設(shè)成比其他交換區(qū)更高），那也成。Disk Bottlenecks （磁盤瓶頸）現(xiàn)象: 至少一個以上硬盤持續(xù)高使用率(GBL_DISK_UTIL_PEAK 50 or highest BYDSK_UTIL 50%). 明顯的隊列深度(GBL_DISK_SUBSYSTEM_QUEUE 3 or anyBYDSK_REQUEST_QUEUE 1). 繁忙硬盤上的響應(yīng)時間長 (BYDSK_SERVICE_TIME 30 andBYDSK_UTIL 30) 進程或線程受阻于IO等待 (PROC_STOP_REASON =CACHE, DISK, IO).磁盤瓶頸是容易解決的:重新編寫你的程序，保證所有的數(shù)據(jù)一直保持在內(nèi)存里!內(nèi)存老便宜了?？杀氖?，這不總是(其實是從來不是)可能的。次好的方案是優(yōu)化你的磁盤解決IO熱點。理想的情況是把磁盤IO分布在盡可能多的IO卡、LUN和物理硬盤上來避免任一特定IO路徑上的瓶頸?？杀氖?，這也不總是可能的，因為程序的設(shè)計、重新布署所需的停機時間等等。要找出熱點，通過性能分析工具顯示不同磁盤設(shè)備的利用率。sar和iostat都有獨立磁盤的信息，Glance和PA就更不用說了。 ，可以以IO卡(HBA)為單位分析。分析通常這樣開始，查看歷史數(shù)據(jù)，重點在性能問題發(fā)生時間段中最繁忙的硬盤。通過BYDSK_UTIL metric過濾數(shù)據(jù)，觀察利用率發(fā)展的趨勢，然后通過BYDSK_REQUEST_QUEUE觀察隊列情況。如果你不是觀察性能問題發(fā)生時的數(shù)據(jù)，那你優(yōu)化的對象可能會搞錯!如果一個硬盤在50%以上的時間繁忙，并且對應(yīng)有等待隊列，就有可能需要優(yōu)化。注意PA的metric GBL_DISK_UTIL_PEAK不是一個平均值，也不是只針對一個硬盤。它是反映在一個時間段內(nèi)最繁忙的那些硬盤的利用率，不同時間段內(nèi)最繁忙的硬盤完全有可能是不同的。另一個有用的全局metric是GBL_DISK_SUBSYSTEM_QUEUE,顯示平均有多少個進程受阻于IO等待。很多舊時的性能磚家喜歡用磁盤的平均響應(yīng)時間(Average Service Time)來做瓶頸的指標(biāo)。比正常值偏高的響應(yīng)時間的確可能指示瓶頸的出現(xiàn)，但是，注意你需要只衡量繁忙硬盤的響應(yīng)時間! 我們要說”硬盤繁忙度低于10%的時候Service time metric根本就是狗屎”. 我們的粗略原則是這樣的:如果硬盤比較忙(BYDSK_UTIL 30)并且響應(yīng)時間比較差(BYDSK_SERVICE_TIME 30,也就是多少毫秒響應(yīng)一個IO請求), 這樣才需要注意。 注意:你會經(jīng)?？吹教囟ǖ牡刂菲骄憫?yīng)時間(average service time)的值非常高，但是跟蹤下去你發(fā)現(xiàn)，這些設(shè)備在做極少甚至沒有IO! 在做海量IO操作的設(shè)備可能有著非常漂亮的響應(yīng)時間數(shù)據(jù)。如果你最忙的硬盤是一個交換區(qū)，那你的問題是內(nèi)存瓶頸，先研究這個問題。也可以看看上面討論交換區(qū)設(shè)置的部分。在磁盤瓶頸出現(xiàn)時Glance可以提供非常有用的信息，因為它能夠分別以硬盤、文件系統(tǒng)、邏輯卷、IO卡()為單位提供報告。你還可以看到邏輯IO與物理IO的對照，物理IO還可以細分為文件系統(tǒng)、裸設(shè)備、虛擬內(nèi)存(paging)和系統(tǒng)級(inode操作)等等?？梢栽赑rocess List中通過PROC_DISK_PHYS_IO_RATE 排序，找到IO操作最多的進程，進一步調(diào)出它打開的文件描述符和位移，這有助于找到具體的問題相關(guān)的文件。對于所有性能分析工具都存在的問題是磁盤內(nèi)部的硬件對它們是不透明的。磁盤陣列可以顯示為一個單獨的硬盤，對陣列內(nèi)部的分析要用到專門的工具。你可能需要從磁盤陣列的供應(yīng)商得到這樣的工具。一些通常可以提升磁盤性能的原則是: 將IO分散到盡可能多的硬盤上，10個硬盤各自10%繁忙比一個硬盤100%繁忙要好。嘗試著把忙的文件系統(tǒng)或是邏輯卷分布到不同的IO卡與磁盤上來獲取最大的吞吐量。 避免過多的日志。不同的應(yīng)用程序有不同的控制方式。對于VxFS,控制intent log是很重要的。vxtunefs可能會有幫助，對于建議的VxFS參數(shù)設(shè)置，參考上面的系統(tǒng)設(shè)置章節(jié)。 如果你足夠細心，可心嘗試通過scsictl命令調(diào)整特定scsi硬盤的最大隊列深度。通常來說增大隊列深度可能會提升并行處理能力，代價是有可能使硬件超負荷。如果你見到QUEUE FULL錯誤信息然后性能出現(xiàn)下降，你就需要把最大隊列深度(max queue depth,scsi_queue_depth)降低。有幾條與磁盤相關(guān)的規(guī)律: IO越小，響應(yīng)時間越短，反之亦然。 串行IO的響應(yīng)時間比隨機IO的短(因為減少了磁頭的移動) 要獲得最大的吞吐量，對串行IO使用大的IO塊大小 最大的緩沖的IO大小是64KB 最大的直接IO大小是256KB (,VxVM補丁可以到1MB) 如果出現(xiàn)跨越邊界的情況會造成一個IO被分成幾個更小的IO，這些情況有:文件系統(tǒng)計塊大小，緩沖鏈(buffer chain)，文件塊(file extent)和LVM LTG邊界。大多數(shù)情況下，系統(tǒng)中大多數(shù)IO是由很有很的幾個進程造成的。注意’濫用’IO的程序 – 產(chǎn)生海量的文件或是做大量的打開、關(guān)閉文件操作?？梢愿鶕?jù)’System’類型的IO來判定是不是這種問題（BYDSK_SYSTEM_IO_RATE ）。要深入分析，可以找做大量IO操作，并且用很多System CPU的程序。 如果在問題發(fā)生時使用Glance,看看Process System Call,調(diào)用是哪些系統(tǒng)調(diào)用。不幸的是，如果你沒有源代碼，那你對編程方面的問題也沒什么好的處理辦法。Stephen還發(fā)現(xiàn)很多人不清楚一樣?xùn)|東叫”寫前讀”,，你需要了解它。無論是通過buffer cache,file cache還是直接訪問都有可能發(fā)生，它有可能會造成性能下降。我們不討論大小、數(shù)字這些其他文檔也可以找到的東西，我們來講一個簡短的Stephen法則。如果你對buffer或是file cache做個小的寫操作，而且buffer或是page還沒有在cache里，或是做裸設(shè)備IO。如果寫操作比8K的buffer或是4K的page還小(或是存在跨界問題),就會讀這個buffer或是page的內(nèi)容，做相應(yīng)的修改后再做寫操作。這絕對會降低小的寫操作、隨機寫操作和直接IO的速度。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,或其他文件服務(wù)的情況，前提是不要因為內(nèi)存壓力。 有些強IO應(yīng)用可能從大的buffer cache獲益，但最重要的是避免pageout發(fā)生。在實際環(huán)境中，我們見到更多的情況是buffer cache設(shè)得太大了。另外，如果你使用一個數(shù)據(jù)庫主要以裸設(shè)備的方式訪問數(shù)據(jù)，那系統(tǒng)的buffer cache也不會發(fā)生作用。 cache,參考上面的核心參數(shù)部分關(guān)于bufpages和dbc_max_pct的內(nèi)容。因為dbc_max_pct可以在系統(tǒng)不重起的情況下更改，可以嘗試通過它來做些測試。就是要記住你如果增加了物理內(nèi)存，buffer cache的大小也會跟著增加。我們堅決反對在HPUX cache。如果根據(jù)上面的的現(xiàn)象，你懷疑buffer cache可能太大了，而且你經(jīng)?？吹絻?nèi)存利用率超過90%,而且你的Buffer Cache比1GB還大，那就把它改小點，改成比它現(xiàn)在的一半多點或是1GB. 改完了以后，再觀察一下命中率。如此反復(fù)。最主要的目標(biāo)是降低內(nèi)存的使用率避免Paging out.如果你的應(yīng)用程序可以從很大的cache獲益，你也有足夠的空閑內(nèi)存，那就配大些。有見過一個用戶配過387GB!Networking Bottlenecks現(xiàn)象: 高的網(wǎng)絡(luò)傳輸數(shù)據(jù)量 (與配置相關(guān)) 或是高的利用率(BYNETIF_IN_BYTE_RATE or BYNETIF_OUT_BYTE_RATE or BYNETIF_UTIL 2*average). 任何的輸出等待隊列 (GBL_NET_OUTQUEUE 0). 比正常時更多的進程受阻于網(wǎng)絡(luò) (PROC_STOP_REASON = NFS, LAN, RPC, Socket (if not idle), orGBL_NETWORK_SUBSYSTEM_QUEUE average). 一個CPU有高的系統(tǒng)模式或是中斷類型的利用率，而其他的CPU大部分空閑 (BYCPU_CPU_INTERRUPT_UTIL 30). 由lanadmin的輸出，經(jīng)?？吹较铝行畔⒃黾?“Outbound Discards” or “Exces