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