AIX常見故障報錯及解決方案

1、 AIX 常見故障報錯及解決方案 大多數(shù)情況下，順著報錯順藤摸瓜很快就能找出原因，但總有例外，有些報錯信息或者日志恰恰讓我們南轅北轍。讓我們看看這些案例最終是如何處理的案例1：圖省事，搞出來個大麻煩生產(chǎn)中心有幾套VIOS環(huán)境，正常運行了1-2年，今日發(fā)現(xiàn)有2套進行健康性檢查，發(fā)現(xiàn)執(zhí)行命令就hang在哪里不動了，又是內(nèi)存不夠用了。0403-031 The forkfunction failed. There is not enough memory available.好奇怪，到底內(nèi)存被誰用了，vios好端端的就這樣了。都這個樣子，重啟vios分區(qū)吧。重啟完，vios順利登陸，執(zhí)行健康性檢查沒啥

2、問題，可是用nmon看了一下內(nèi)存使用分配了4個G，使用1個多G,慢慢慢慢的就看到內(nèi)存使用越來越大，不一會4個G就用完了，重啟其他vios分區(qū)一個樣子，連換頁空間都用了。頓時一頭霧水。到底發(fā)生了什么呢？生產(chǎn)中心有幾套VIOS環(huán)境，正常運行了1-2年.突然出現(xiàn)這種問題，首先想到的是變更。梳理了近期變更操作，近期新部署了PowerVC,VIOS進行了補丁升級。VIOS2.1升級到VIOS2.2.3.首先，重啟vios分區(qū)，在內(nèi)存沒有用完前趕緊檢查那個進程使用的內(nèi)存.排名第一的是vio_daemon,觀察了一會發(fā)現(xiàn)內(nèi)存一會就被他占用完了第二，元兇找到了，vio_daemon到底是干啥的，問問IBM80

3、0吧，IBM回復(fù)問我收集一下系統(tǒng)信息。1.ioslevel2./etc/security/limits的輸出反饋后，IBM告訴我，我遇到了bugvios版本和 /etc/security/limits stack = -1完全符合這個bug特征。其實這個bug是可以避免的，我們大多數(shù)實施AIX的時候,很容易順手把 /etc/security/limits.都改成-1，在大多數(shù)情況下，沒啥問題，但是就是在這個版本下就容易遇到這個問題。default: fsize = -1 core = -1 cpu = -1 data = -1 rss = -1 stack = -1 nofiles = -1T

4、he problem can be due to a known issue inVIOS thru with vio_daemon having a memory leak that was fixedat with IV64508,or it could be due to incorrect VIOS settings.AnswerTo check your VIOS level, as padmin, run:$ ioslevelIf your VIOS level is or higher, the problem ma

5、y be due to the VIOShaving incorrect system settings in /etc/security/limits. If thestack size is set to unlimited (stack = -1),this exposes a condition where the system can be allowed to pin as much stackas desired causing vio_daemon to consume a lot of memory.$ oem_setup_envvi /etc/security/limits

6、 -check thedefault stanzadefault:fsize = -1core = -1cpu = -1data = -1rss = -1stack = -1nofiles = -1In some cases, the issue with vio_daemonconsuming high memory is noticed after a VIOS update to 2.2.3.X. However, aVIOS update will NOT change these settings. It is strongly recommended not tomodify th

7、ese default values as doing so is known to cause unpredictableresults. Below is an example of the default values:default:fsize = 2097151core = 2097151cpu = -1data = 262144rss = 65536stack = 65536nofiles = 2000To correct the problem change the setting back to default values.Then reboot the VIOS at yo

8、ur earliest convenience.案例2：裝個AIX，卻裝出了信任危機某制造業(yè)用戶，一個新項目著急要上線，讓維保廠商工程師趕緊抓緊準(zhǔn)備一個AIX資源，裝AIX系統(tǒng)按說對ma工程師來講應(yīng)該輕車熟路，可是這次裝了好幾遍，AIX系統(tǒng)就是進不去。1 懷疑光盤問題，更換好幾張重裝未果，依舊進不去2 懷疑AIX版本，更好了兩個未果3 懷疑硬件，進入asm里也沒啥報錯首先說下用戶設(shè)備的背景信息，設(shè)備采購于2012年，“天工計劃”中的一款產(chǎn)品Power710 和Power730 中的一款，Power710設(shè)備特點：定位應(yīng)用服務(wù)器，價格便宜，也就是不需要HMC管理，使用串口安裝的IVM部署管理虛擬

9、化環(huán)境。之前這臺710用作應(yīng)用服務(wù)器。串口部署過IVM環(huán)境，這次重裝需要注意串口輸出問題。所以一定要進行如下配置才可以順利進入系統(tǒng)第一步：進入維護模式 如果進入 Maintenance Mode 步驟就省略了第二步：#export TERM=vt100# smit chtty紅色標(biāo)注的兩行，增加clocal.syncsyncsyncreboot之后就能順利進行系統(tǒng)了。案例3：安裝AIX報出這個錯，新手老手絕對沒見過相信社區(qū)大多數(shù)人都安裝AIX幾十遍甚至上百遍了，但是今天安裝AIX報出這個錯，新手老手絕對沒見過安裝AIX停在了這里。其實我也經(jīng)過了很多各位的排查工作，最終梳理了一下發(fā)現(xiàn)AIX安裝出

10、問題，排除硬件介質(zhì)問題，多半是配置問題，那就按照這個思路往下走首先，既然是配置就去profile文件里看看。不查不知道，一查問題果然找到了有人會說，你居然犯這么低級的錯誤。冤枉啊，這是PowerVC干的怪我背景沒說清楚。這是PowerVC部署aix出現(xiàn)的問題.第二，問題找到了，那么為什么會出現(xiàn)問題，部署分區(qū)profile配置是在Powervc設(shè)置的，那就去Powervc里找答案吧。問題出在了這里.PowerVC納管了很多主機，每臺主機配置不盡相同，當(dāng)初為了省事就配置了vary計算模板，最大cpu配置成了32。實際部署AIX時候，選擇了一臺低配的power服務(wù)器，CPU配置沒有32，只有20個，

11、結(jié)果被PowerVC配置成25.6.就這樣出現(xiàn)了問題。反思這個問題，PowerVC,規(guī)劃配置模板，盡量多配置幾個計算模板，與服務(wù)器相匹配.避免此類問題的發(fā)生。通過這個問題還有第二種解法：kdb模式下 輸入 f，查看堆棧信息，也可以順勢查到profile配置信息案例4：執(zhí)行l(wèi)srep，詭異報出Insufficient memory執(zhí)行l(wèi)srep，詭異報出Insufficient memory檢查vios分區(qū)內(nèi)存使用情況似乎跟內(nèi)存毫無關(guān)系。首先檢查了其他vios有沒有這個問題，發(fā)現(xiàn)均沒有此現(xiàn)象發(fā)生。對比vios版本及其lsrep輸出，發(fā)現(xiàn)vios版本。都一樣，唯一不同的是出問題的這個vios /v

12、ar/vio/VMLibrary沒有iso。把幾個AIX ISO傳到有問題的這個vios /var/vio/VMLibrary下后，再次執(zhí)行l(wèi)srep，成功了案例5：PowerHA給Oracle新增表空間，遭遇memory croedump通過PowerHA給Oracle新增表空間，使用C-SPOC在線添加LV,開始給Datavg添加，很順利，添加了10個很成功，在繼續(xù)添加新的lv后，居然報錯了. memory croedump.1，內(nèi)存不夠用了嗎.看了一下確實有點緊張hostA:hostB:2，仔細看了一下Powerha日志也沒啥有價值的信息難道真的是內(nèi)存快用完了導(dǎo)致的。3，由于還要給其他v

13、g新增lv，所以又嘗試了一下給其他vg添加一下lv試試。居然成功了。這個問題從內(nèi)存報錯開始容易給人內(nèi)存不足假象，實際環(huán)境確實也是內(nèi)存利用率很高，但是定位最終問題不是內(nèi)存不足造成的。首先，剛開始新增的幾個lv都順利，后幾個就失敗了，然后新增其他vg的lv也成功了，這個時候就開始懷疑遇到bug了。第二，一般裸奔的powerha，遭遇bug的可能性比較大，檢查一下powerha補丁情況吧果然，基本上就是一個裸奔的Powerha環(huán)境，遇到bug也就不足為奇了第三，既然懷疑是bug，那就找點說服力的東西出來.如下所示IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEM

14、ORY FAULTA fix is availableObtain the fix forthis APAR.Error descriptionThe clpasswdremote utility is core dumping due tosegmentationfault.The problem occurs when the user is missing in/etc/passwdin one of the nodes in the cluster.The cspoc.log will log the following:= C_SPOC COMMAND LINE=/usr/es/sb

15、in/cluster/sbin/cl_chpasswd -cspoc-f -r-cspoc -grg1 test3hacmp13: success:/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.origtest3hacmp14: FAILED: evalclpasswdremote -u test3 -praCYOSMwhoJU. -f 2 -l 0hacmp14: cexec54: 3735594 Memoryfault(coredump)hacmp14: RETURN_CODE=139hacmp14: cl_rsh had exit co

16、de =139, see cspoc.logand/or clcomd.log for more informationThe error report will log a CORE DUMP error with thefollowing stack trace:main 94main 88_start 6CThe following symptom code is logged as well:PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11FLDS/mainVALU/94 FLDS/_startLocal fixEnsure

17、 that the user exists in /etc/passwd file in all ofthe nodes in the cluster.Problem summaryIf a user is not created using cspoc so that it exists onall nodes in the cluster, then if you try to change thatusers password cluster wide using cspoc, clpasswordremotewill core dump on nodes where the user

18、is not configured.The smit output will look like:Changing password for tstuserhack2: cexec 54 : 8781858 Memory fault(coredump)Problem conclusionA check was added to clpasswdremote to avoid attempting tochange the password on a node where the user is not defined.案例6：V7000緊急的狀態(tài)，緊急的處理使用PowerVC,部署AIX分區(qū)，

19、結(jié)果無法部署，報了一堆莫名其妙的錯誤。怪了前幾天還能正常部署.今天就不能了檢查PowerVC服務(wù)都正常.登錄HMC看看有沒有建立分區(qū)profile，發(fā)現(xiàn)沒有.無功而返，返回PowerVC繼續(xù)排查，到了存儲器發(fā)現(xiàn)了端倪，不過看樣子挺嚇人。V7000存儲卷運行狀況變成了緊急。登錄V7000查看，發(fā)現(xiàn)V7000沒有問題。那就怪了。其實PowerVC里的關(guān)于V7000的狀態(tài) 緊急不能反映V7000真正的狀態(tài)，而是通信出現(xiàn)了導(dǎo)致。至于通信出現(xiàn)問題，事后問網(wǎng)絡(luò)的人，我部署的期間，網(wǎng)絡(luò)正在變更，導(dǎo)致PowerVC不能下發(fā)命令給V7000，PowerVC就把V7000標(biāo)記成緊急了。案例7：一次先入為主的異常故

20、障處理！一臺P740服務(wù)器通過SAN交換機鏈接一臺DS4700存儲，在硬件維保商更換一次存儲電池（A控）后，業(yè)務(wù)中斷了。我司負責(zé)數(shù)據(jù)庫以及系統(tǒng)維護，被客戶CALL到現(xiàn)場檢查問題，在一番查看后發(fā)現(xiàn)A控上面所有LUN都找不到了，問題找到后開始排查問題。詢問硬件維保商在更換電池時有沒有動到其他東西，得到了很準(zhǔn)確的回答，我們就換個電池其他啥也沒用動。于是連接存儲SM把A控所有LUN切到B控，系統(tǒng)內(nèi)能看到所有盤，OK 問題在A控上面，SM中看到的存儲無報錯無問題，繼續(xù)把原來A控的LUN切到A控中，系統(tǒng)又找不到了開始刪除所有硬盤然后重新識別還是不行忙來忙去 兩三個小時過去了，客戶在旁邊一直說啥時候能搞好啊

21、，硬件維保商的人沒事似的在旁邊坐著我要去機房看一下，必須看一下?？蛻魩е覀兿铝藱C房，然后看了主機以及HBA卡連接線，一切看起來都那么美好。然后看到了存儲A控出的那條光纖線你媽的插錯了！ 客戶用異樣的眼光看著硬件維保商處理問題切勿先入為主，任何事要自己確定一下以免有誤！案例8：varyonvg報錯(LVM相關(guān))的分析及處理AIX操作系統(tǒng)在做計劃內(nèi)升級操作系統(tǒng)版本變更時，發(fā)現(xiàn)對于VG的varyon和varyoff命令有告警信息，經(jīng)分析這只是一個告警信息，不影響使用，具體告警信息如下：系統(tǒng)環(huán)境：AIX 5.3 TL12 SP7首先，分析當(dāng)時的報錯內(nèi)容，從操作內(nèi)容來看，可以看到在執(zhí)行varyoffv

22、g命令時底層調(diào)用lqueryvg子命令時報錯，而lqueryvg是一個查詢類的命令，從這個命令的返回內(nèi)容說明VG的定義信息與VGDA描述不一致。對于這類型的告警信息，重啟操作系統(tǒng)時便會自動更新VG的相關(guān)信息進行自動修正。而當(dāng)時計劃內(nèi)的變更是升級操作系統(tǒng)并修改磁盤的reserve_policy屬性，因此打完補丁后直接重啟操作，在這個過程中已經(jīng)把VG信息進行了更新。然后，分析當(dāng)時的操作步驟及LVM的日志進行驗證對應(yīng)。當(dāng)時的操作記錄如下，從操作日志來看，在重啟操作系統(tǒng)前執(zhí)行過兩次varyoffvg和一次varyonvg的操作：分析當(dāng)時的LVM的日志，可以看到第一次varyoffvg時出現(xiàn)讀取VG信息不一致的報錯。在第一次varyonvg時出現(xiàn)現(xiàn)樣的信息。在第二次varyoffvg時也現(xiàn)現(xiàn)同樣的信息。上面信息是操作系統(tǒng)重啟前的信息，下面分析操作系統(tǒng)重啟后LVM相關(guān)的信息，從日志中來看，當(dāng)操作系統(tǒng)重啟后，VG在varyon時返回值為0，說明重啟過程已經(jīng)更新了VG的信息。綜上所述，在重啟操作系統(tǒng)后已經(jīng)自動更新