AIX性能問題診斷及調(diào)優(yōu)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上在AIX日常運維中，性能問題一直是一個很重要的問題，為了讓操作系統(tǒng)能正常平穩(wěn)高效的運行，便需要一些武功秘籍來進(jìn)行快速定準(zhǔn)并解決問題，本次我們便來討論一下我們可以用到的武功秘籍。所謂性能問題，主要幾種在CPU、內(nèi)存、I/O三個大類別，因此我們分類進(jìn)行討論。類別一： CPU檢查系統(tǒng)的三把斧頭一招便是topas，這個是最常用也是最有效的一招，通過topas的輸出可以看到CPU的使用情況。從topas的輸出我們主要關(guān)注如下4個指標(biāo)：User%：主要是應(yīng)用程序消耗CPU的百分比Kern%：主要是操作系統(tǒng)本身消耗CPU的百分比Wait%：主要是有I/O問題時，CPU等待I/O的百

2、分比Idle%：那么這個一定是空閑的CPU了那么判定系統(tǒng)忙不忙的一個指標(biāo)為Idle%，正常情況下，Idle%的值如果低于10%，則這個系統(tǒng)的CPU就需要注意了，此時關(guān)注一下是User%高還是Kern%高，如果是User%高，則說明是應(yīng)用程序占用CPU較多，反之則說明操作系統(tǒng)本身占用CPU較高。(但是請注意：并不是所有Kern%高都是操作系統(tǒng)本身導(dǎo)致的，也有可能是應(yīng)用程序調(diào)用了系統(tǒng)本身的函數(shù)，這樣也會把這部分消耗算在Kern%頭上)在拍完第一板斧后，我們繼續(xù)向下分析，拍第二板斧trpof，這個可以理解為精簡版的trace，一般情況下執(zhí)行這個命令對系統(tǒng)負(fù)載影響不太大，因此可以用這個工具先粗略看一下

3、相關(guān)的進(jìn)程。tprof -skeuj -x sleep 10通過tprof可以看出占用CPU排名靠前的進(jìn)程。如果root cause還沒有找到，那么便使出大招，收trace數(shù)據(jù)。在收集trace數(shù)據(jù)前請先注意以下原則： 收集trace數(shù)據(jù)會對當(dāng)前系統(tǒng)的負(fù)載有影響，在CPU已經(jīng)達(dá)到99%時，再收集trace有可能把操作系統(tǒng)搞夯。 一定要等到問題重現(xiàn)時收集trace，由于trace產(chǎn)生的數(shù)據(jù)量巨大，因此要收集有效時間段的trace。如果不確定問題什么時候重現(xiàn)，可以寫個判斷腳本，收集循環(huán)trace。 用root用戶進(jìn)行trace收集 需要預(yù)估trace數(shù)據(jù)的大小，然后根據(jù)預(yù)估的空間，在操作系統(tǒng)上找一

4、個空間較大的地方存放數(shù)據(jù)。trace數(shù)據(jù)的大小可以用下列公式算出：預(yù)估數(shù)據(jù)大小=邏輯CPU的個數(shù) * 10MB(其中邏輯CPU的個數(shù)可以用vmstat | grep -i lcpu命令查看)在了解上述原則后，我們開始收集trace數(shù)據(jù)。trace -anl -C all -T 20M -L 40M -o /bigFS/trace.rawsleep 10trcstop在執(zhí)行完上述收集命令后，會生成trace的raw文件。下面對trace數(shù)據(jù)進(jìn)行轉(zhuǎn)換：trcrpt -r -C all trace.raw > trace.r再用curt進(jìn)行數(shù)據(jù)處理：curt -i trace.r -o cur

5、t.out -pest此時產(chǎn)生一個curt.out文件，可以直接進(jìn)行閱讀。首先可以從“System Summary”字段看到各種類型的進(jìn)程分別占用CPU的比例。然后從“Application Summary”可以看到應(yīng)用占用CPU的排名。也可以從“System Calls Summary”可以看到系統(tǒng)函數(shù)調(diào)用排名情況。OK，到此我們便把這三把斧拍完了，那么我們來討論一個真實的案例，來從中看看這三把斧是怎么拍的。故障描述：生產(chǎn)環(huán)境CPU使用率高，導(dǎo)致應(yīng)用程序運行緩慢，批量程序無法按時完成。系統(tǒng)環(huán)境：AIX 6100-07-05處理過程：Step1，使用topas查看，發(fā)現(xiàn)CPU使用率很高，其中大

6、部分為Kern%占用Step2，收集tprof數(shù)據(jù)，tprof -skeuj -x sleep 10，找到占用CPU最高的兩個進(jìn)程。/cd41/cdunix4100/ndm/bin/ndmsmgr/cd41/cdunix4100/ndm/bin/cdpmgrStep3，收集trace數(shù)據(jù)，并進(jìn)行分析，發(fā)現(xiàn)絕大多數(shù)是系統(tǒng)調(diào)用。當(dāng)時以為是操作系統(tǒng)的BUG或者操作系統(tǒng)本身導(dǎo)致的，初步判斷和應(yīng)用程序沒有關(guān)系，但后來證明當(dāng)時這個想法是錯誤的，這也說明并不是所有kernel高是由于系統(tǒng)本身造成的，如果應(yīng)用程序調(diào)用系統(tǒng)本身函數(shù)，也算在kernel頭上。JStep4，通過curt文件輸出，看到占用kernel

7、最高的是paged_ds_start函數(shù)。Step5，分析調(diào)用paged_ds_start函數(shù)的進(jìn)程為ndmsmgr，這是一個應(yīng)用的進(jìn)程!Step6，那么分析ndmsmgr為什么會調(diào)用較高的kernel運算。使用truss命令跟蹤這個進(jìn)程。經(jīng)分析這個進(jìn)程在對文件進(jìn)行操作完成后對文件執(zhí)行close操作時有報錯，返回值為ERR#9 EBADF，該報錯表述有無效的文件描述符，經(jīng)查發(fā)現(xiàn)這進(jìn)程會調(diào)用close函數(shù)，把文件描述符從0到65533的文件全部關(guān)閉一遍。也就是說應(yīng)用進(jìn)程在調(diào)用大量的close()函數(shù)導(dǎo)致系統(tǒng)kernel使用率飆升! 這也就把耗資源的賬偽造到了kernel頭上。J最終升級應(yīng)用程序解

8、決了該問題。類別二： 內(nèi)存下面我們來討論內(nèi)存的使用情況，首先也可以使用topas命令進(jìn)行內(nèi)存使用情況的查看。從topas的輸出中可以看到物理內(nèi)存共有64GB，paging space共有16個GB。其中物理內(nèi)存部分：計算內(nèi)存使用了27%，文件系統(tǒng)緩存使用了9%。那么問題來了，真正用于運算的內(nèi)存是多少呢？答案是物理內(nèi)存的27%。切記一定不要把文件系統(tǒng)緩存的使用當(dāng)成內(nèi)存的真實消耗。因此當(dāng)有新的內(nèi)存申請時，文件系統(tǒng)的緩存是可以被換出來的。那么一般來看，當(dāng)計算內(nèi)存達(dá)到90%時，則系統(tǒng)就會有性能問題；當(dāng)達(dá)到95%以上，一般就會產(chǎn)生內(nèi)存換頁，這時就會把物理內(nèi)存中的數(shù)據(jù)換到了paging space中，而如

9、果短時間內(nèi)有大量的換頁產(chǎn)生，就很有可能引起操作系統(tǒng)夯，而如果在有HACMP或者oracle RAC集群環(huán)境中，就有可能導(dǎo)致集群強(qiáng)制把操作系統(tǒng)重啟。因此對計算內(nèi)存的監(jiān)控非常重要。說到內(nèi)存，不得不說的是svmon這個命令，這個命令可以查看更細(xì)的內(nèi)存使用情況，例如每個進(jìn)程占用多少內(nèi)存等等信息。可以用svmon -G命令查看內(nèi)存的整體使用情況。那么問題又來了，這個輸出應(yīng)該怎么看？圖中virtual字段是真實消耗的計算內(nèi)存的業(yè)面數(shù)，size是物理內(nèi)存的業(yè)面數(shù)，因此計算內(nèi)存的比值=/=27%。那么如何查看每個進(jìn)程所使用的內(nèi)存量呢？可以用svmon -P <PID>來進(jìn)行查看。在下圖中這個例子中

10、可以看到計算內(nèi)存的使用量共有11804個4K頁面+個64KB頁面。換算為4KB頁面共有個。但注意：這些內(nèi)存有些是這個進(jìn)程獨享的，有些是多個進(jìn)程共享的，因此在進(jìn)行總和分析時不能簡單的把所有內(nèi)存值相加。下面我們來看看占有內(nèi)存的排名情況，我們要按占用內(nèi)存的量由多到少進(jìn)行排列，這個可以按如下方式進(jìn)行(注意：最后一列已經(jīng)換算成MB)：那么對于目前AIX 6.1和AIX 7.1版本，常見的幾個建議調(diào)優(yōu)的參數(shù)如下：- minperm% = 3- maxperm% = 90- maxclient% = 90- lru_file_repage=0- default from AIX 6.1. lru_file_

11、repage set to 0 makes repage rates to be ignored when determining what kind of page to steal, means filecache will be steal when above minperm.- strict_maxperm%=0另外，perfPMR也是收集性能數(shù)據(jù)常用的工具，下載網(wǎng)址如下：可以用perfPMR提供的腳本進(jìn)行memdetails.sh進(jìn)行更詳細(xì)的內(nèi)存數(shù)據(jù)收集。也可以使用nmon對內(nèi)存進(jìn)行分析，可以看到一天內(nèi)的內(nèi)存整體使用情況。其中深紅色的為計算內(nèi)存，淡藍(lán)色的為文件系統(tǒng)緩存，黃色的為文件

12、系統(tǒng)緩存。也可以按進(jìn)程看到占用內(nèi)存的情況。類別三： I/O談起I/O不可避免的要首先了解LVM相關(guān)的一些技巧。我們先談?wù)刲v的mapping關(guān)系，這個東西說起來很簡單，但實際上它和I/O的性能和LV誤刪后的恢復(fù)有密切的關(guān)系，因此了解清楚LV映射對于系統(tǒng)運維有很大的幫助?？梢酝ㄟ^lslv -m <lvname>看到lv的分布情況。這個排序是按著LP的編號進(jìn)行的，這個順序很重要，如果lv被誤刪后，可以根據(jù)這個排序把lv重建回來。通過fileplace命令也可以看到詳細(xì)的分布信息。通過readvgda <hdisk>可以通過磁盤讀取到VGDA的信息，這里邊包含了所有LV的mapping信息。因此經(jīng)常備份vgda信息對于災(zāi)難恢復(fù)很有必要。通過getlvcb命令可以得到LVCB的信息。在了解完了LV的分布后，我們回到性能監(jiān)控上，iostat是一個很好用的命令。通過這個命令可以看到每個磁盤的繁忙程度、響應(yīng)時間、是否有I/O排隊等信息。topas -D也可以看到磁盤的相關(guān)信息。但在topas輸出中一定注意CPU中的idle%