轉自@twt社群，作者陳熾卉
1 CPU 監控
本示範場景，主要是通過 ncpu 模拟應用對 DLPAR 分區的 CPU 加壓；然後通過 nmon 觀察消耗 CPU 最高的程序。
1.1 檢視 CPU 消耗最高的程序以及其 CPU 占用情況
登入 AIX，運作 nmon，輸入“t”然後輸入“2”:
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-o11L3Cic-1613975480742)(https://pic2.zhimg.com/80/v2-1f14cba5741d259d559b424210dba045_720w.jpg)]
輸出結果為占用 CPU 最高的各程序排序，可以看到 CPU 主要由 rtsdb 程序消耗。
1.2 使用 truss 指令跟蹤系統調用情況
如果 nmon 顯示某些程序的系統 CPU 消耗很高，可以使用 truss 對特定程序進行跟蹤分析。
跟蹤共享庫或者使用者library調用。
示例：取得程序系統調用的統計情況，truss -c -p 一段時間之後，然後Ctrl+C:
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-oTnenE4X-1613975480747)(https://pic3.zhimg.com/80/v2-7b9f0e69db9515873a2983112e88e3fa_720w.jpg)]
truss跟蹤程序的執行，預設truss将跟蹤到程序結束運作，可以Ctrl + C手工終止:
用-t選項根據具體的系統調用，如下：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-RIrCFjEs-1613975480749)(https://pic1.zhimg.com/80/v2-2c3f139676570a9895e95e2914298564_720w.jpg)]
用-u跟蹤共享庫，例如libc.a:
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-vuRBpsCb-1613975480750)(https://pic1.zhimg.com/80/v2-9324d8edf424bd8d0c12b96edebb502c_720w.jpg)]
1.3 使用 procstack 指令跟蹤程序的執行棧資訊
procstack 可以提供類似 dbx 列印執行棧的功能，但不會阻塞應用執行。這可以用來輔助分 析應用 hang，或者鎖沖突很高等等問題。
例如系統顯示鎖沖突很高，且主要系統 CPU 消耗在某程序，與此同時，如果多次 procstack 觀察到該程序出現相同的鎖調用模式，則這很可能就是觸發問題的原因：
1.4 使用 tprof 指令觀察系統整體 CPU 使用分解情況
運作 tprof 指令，其中 -E 參數訓示 tprof 使用基于 Power7 Performance Monitor Unit (PMU)的采樣方式生成剖析報 告。相比預設的基于時鐘的方式，基于 PMU 的采樣方式可以提供更精确的剖析報告，尤其 在某些 kernel 代碼區域中斷被關閉的情況下。
-u 表示 user profiling;
-s 表示 shared library profiling;
-k 表示 kernel profiling;
-e 表示 kernel extension profiling;
-j 表示 java profiling;
-l 訓示 tprof 報告顯示函數名稱時不進行截斷，顯示長名字;
-L 用于指定應用程式的路徑，例如本處 rtsdb 的路徑為/tmp/nstress;
-t 訓示 tprof 報告按線程進行分解；
-r 訓示生成的報告名稱;
-x 訓示 tprof 運作的程式; tprof 的資料收集為該程式運作的整個生命周期;
Tip: 有時 tprof 可能出現不顯示函數名稱而隻看到函數位址的現象，這主要有如下幾種原因：
- 未指定相關二進制程式或共享庫路徑，可以在 tprof 選項中加上：-S <應用程式所在 路徑:應用共享庫路徑>
- 二進制程式被 strip 過，去除了符号調試資訊；建議檢查去除編譯腳本中的 strip 命 令，或去除編譯指令中的-s 選項；
或者直接按符号位址，通過 dbx 查詢其對于函數名稱：通過 gencore 生成相關程序的記憶體鏡像檔案， 并通過 dbx 進行解析，如下：
PS：直接通過 dbx 進入程式也可以直接檢視函數位址，但如果需要同時檢視相關資料結構的 話，就需要 gencore 生成一份程序記憶體鏡像了。
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-znKvZAfT-1613975480752)(https://pic1.zhimg.com/80/v2-93d775396cffbaabe65412a32fab27d0_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-RbvQggEs-1613975480753)(https://pic4.zhimg.com/80/v2-eed4b62ebeabb92a6c5d8fe3365090eb_720w.jpg)]
據此，可以看到CPU主要消耗在rtsdb 程序上；而 rtsdb 程序的 CPU消耗主要在 User和 Shared 兩部分，這兩部分都對應 CPU 統計的 usr%部分。
對 tprof 報告的輸出部分進一步追蹤可以看到，USER 部分 CPU 主要消耗在 ncpu.c 的 work 函 數：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-PNsx6PSQ-1613975480753)(https://pic4.zhimg.com/80/v2-00428a7f48e187901718c606efb538ff_720w.jpg)]
而 SHARED 部分 CPU 主要消耗在 libc 庫的除法調用(divu64)函數：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-D0SaZvYT-1613975480754)(https://pic4.zhimg.com/80/v2-ab3f925d2f03370ea976bdbcf5151d5b_720w.jpg)]
至此，我們就可以得到 CPU 占用率優化的方向，重點分析上述幾個 CPU 占用率高的函數調 用及其來源。注意一般而言，上述部分可能存在對應關系，例如很可能是 USER 部分的 work 函數調用了 SHARED 部分的__divu64 函數。
2 記憶體監控
2.1 AIX 記憶體配置設定回收政策介紹
AIX 系統為每個業務程序維護一個獨立的空閑記憶體清單；同時采取相應的政策，使得對于該 程序的記憶體申請/釋放盡量在此空閑清單中進行。這樣可以提高配置設定效率，不需要每次記憶體 配置設定都經過系統核心。程序退出後，系統會回收該程序占用的全部記憶體。詳情參考：
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.genp rogc/doc/genprogc/sys_mem_alloc.htm
注：選擇不同的配置設定政策時 , 對空閑記憶體空間的管理政策會有所差異。例如預設的管理結構是 cartesian 樹；而采用 watson 配置設定算法時，使用的管理結構是紅黑樹。
2.2 記憶體配置設定觀察示例—遞增配置設定
程序的詳細記憶體配置設定情況可以使用svmon來觀察，參考如下示例。需要注意，為友善svmon觀察，示例代碼需要在malloc之後調用memset進行初始化；因為作業系統實際上并不會立即對已申請但尚未通路到的内容配置設定實際存儲空間，而是推遲到第一次通路時 才會實際配置設定—這即是缺頁機制的工作原理。
如下是一個申請空間遞增的應用，配置設定/釋放大小為2MB->4MB->8MB->16MB, 則通過各階段的 svmon可以看到，記憶體頁面會持續增長，從2MB一直增加到16MB（注意不是2MB+4MB+…+16MB=30MB）。
Malloc配置設定2MB，未初始化時：
Addr Range: 65534…65535 Address Range為0～512頁，即代表512×4096=2MB虛拟位址空間。Virtual取值為2，表示該空間 尚未實際配置設定。
初始化後：
Virtual取值為513，表明虛存空間已經實際配置設定。
釋放之前申請的2MB，重新申請4MB并初始化後：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-KxuwXYqw-1613975480755)(https://pic1.zhimg.com/80/v2-6e40b349f768c9f6cafdf2b3f02a6748_720w.jpg)]
Addr Range: 0…1024 1024×4096=4MB，此前釋放的512頁虛拟位址空間被重複利用。
釋放之前申請的4MB，重新申請8MB并初始化後：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-rI0bJLTk-1613975480756)(https://pic1.zhimg.com/80/v2-a9b75535b650131631e87bdd43114198_720w.jpg)]
Addr Range: 0…2048 此前釋放的1024頁虛拟位址空間被重複利用。
釋放之前申請的8MB，重新申請16MB并初始化後：
2.3 記憶體配置設定觀察示例—遞減配置設定
如示例，如果是一個申請空間遞減的應用，配置設定/釋放大小為16MB->8MB->4MB->2MB, 通過各階段的svmon（svmon -nrP ）可以看到，記憶體頁面始終維持在16MB。
Malloc配置設定16MB，未初始化時：
Address Range為0～4096頁，即代表4096×4096=16MB虛拟位址空間。Inuse/Virtual取值為2， 表示該空間尚未實際配置設定。
初始化後：
Virtual=4097頁, 虛拟記憶體已經實際配置設定。
釋放之前申請的16MB，重新申請8MB并初始化後：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-DtnbHp6Y-1613975480757)(https://pic2.zhimg.com/80/v2-613acfeef55e5736316fbe7726a800e1_720w.jpg)]
釋放之前申請的8MB，重新申請4MB并初始化後：
釋放之前申請的4MB，重新申請2MB并初始化後：
可以看到svmon輸出結果沒有變化；原因是雖然應用調用了free釋放了16MB記憶體，但系統的處理 政策是将該記憶體置于程序自身的空間塊樹中管理。下一個8MB配置設定，實際上是直接從程序已有的 16MB空閑塊中擷取的。但對系統而言，程序管理的空閑塊樹也對應為該程序的記憶體消耗，是以 其記憶體占用沒有變化。
測試代碼：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-FQZSgpnM-1613975480759)(https://pic3.zhimg.com/80/v2-1453e0dbf12695ddfb6bbd23f30f296e_720w.jpg)]
2.4 觀察系統中記憶體占用最高的程序（svmon 方法）
背景運作 3 個 nmem64 程序：
./nmem64 -m 2048 -s 3000 -z 80 &
按程序使用的虛拟記憶體進行排序，顯示占用最高的前三項：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-te5QvCsB-1613975480760)(https://pic4.zhimg.com/80/v2-3be0402623dd42794465008d6b769753_720w.jpg)]
顯示虛拟記憶體占用最高的 3 個程序的詳細的記憶體段分布資訊，如下：
可以看到，消耗最多虛拟記憶體的段都是 nmem64 程序的資料段。
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-IoU20jMQ-1613975480760)(https://pic3.zhimg.com/80/v2-46a7a2e01a038e82deb78c32229fe25e_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-GNXQ00gu-1613975480762)(https://pic2.zhimg.com/80/v2-ce8bbc24a33387d6942886785d2a5041_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-Qn6EbtX0-1613975480762)(https://pic3.zhimg.com/80/v2-912dbf96ccd3f3ded6b411473f7ff64a_720w.jpg)]
2.5 觀察系統中記憶體占用最高的程序（nmon 方法）
登入 AIX，運作 nmon，輸入“t”然後輸入“4”:
輸出結果為按記憶體使用由高到低的程序排序。
2.6 尋找記憶體持續增長的程序
可以使用 ps vg 記錄目前系統中各程序的記憶體消耗情況，然後通過比較多次 ps vg 的結果來 判斷是否存在一些程序有持續的記憶體增長。說明：程序存在持續記憶體增長并不一定意味着出現了記憶體洩漏。由于 AIX 記憶體配置設定采用了通路時分 配的政策，程序申請大量記憶體時系統并不會第一時間配置設定記憶體，而是在程序使用過程中實際 通路時才進行配置設定。由于這種配置設定政策，程序在啟動初期可能存在記憶體持續增長的可能（例 如資料庫緩存需要一定時間才能完全填充）；但其增長曲線應該是收斂到具體值的。
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-Pv2lXIkg-1613975480764)(https://pic2.zhimg.com/80/v2-a8b429fdfe61b3d19a8fe896d0a1541d_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-5Hz991V9-1613975480764)(https://pic3.zhimg.com/80/v2-79e5b2932fc3326330bca172ca54b7ae_720w.jpg)]
測試腳本如下：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-ph2s9xX6-1613975480766)(https://pic3.zhimg.com/80/v2-b8c82e0c2620782c010247c8008c76ce_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-3u6Wczlf-1613975480766)(https://pic4.zhimg.com/80/v2-007d7cdb313371406a3cb1bd03f9bca7_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-Xnlvkl7n-1613975480767)(https://pic3.zhimg.com/80/v2-91949d94b81c51f0e0f990be74490e3a_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-mD6gK7ZS-1613975480767)(https://pic3.zhimg.com/80/v2-25280528ff20851b24a739f05550f712_720w.jpg)]
2.7 如何通過共享記憶體 ID 對應關聯到該共享記憶體的程序
在 AIX 系統層面，隻要給定共享記憶體 id，就可以擷取 attach 該共享記憶體的程序清單，方法如 下：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-SHNJokag-1613975480768)(https://pic4.zhimg.com/80/v2-d64bc6dd904e69ecf76b4232fb10af7f_720w.jpg)]
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-FadsMHEF-1613975480769)(https://pic4.zhimg.com/80/v2-063e2025c1ff5ffacad8224b3b3df4e3_720w.jpg)]
可以根據其共享段 SID，獲得相應的關聯程序 pid，如下。注意 ipcs 上看 NATTACH=53，即有 53 個程序 attach 到該共享記憶體，是以 svmon 結果中，程序清單部分對應列出了 53 個程序 pid。
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-1VVOnQAJ-1613975480769)(https://pic2.zhimg.com/80/v2-7a0e7b78d7fe017de908d7b3261feab5_720w.jpg)]
根據相應的 pid 可以擷取程序的具體資訊：
2.8 如何擷取 AIX Kernel 的記憶體使用率
kernel大部分記憶體占用采用跟普通程序一樣的記憶體段方式組織，比如kernel heap(這部分記憶體消 耗包含檔案系統的中繼資料、核心擴充、第三方驅動等等), 網絡buffer，磁盤管理LVM buffer占 用，以及一些RAS特性的buffer占用，例如light-weight memory trace buffers, component trace buffers等等。這部分都可以通過svmon -Ss 查詢出**（注意這條指令阻塞時間較長）**。少部分采用非段方式組織的主要是AIX記憶體管理的中繼資料如頁表之類。
可以通過perfpmr.sh -x memdetails.sh 擷取kernel記憶體占用的整體情況，記憶體分布将輸出在 http://perfpmr.int中。
也可以通過如下方法直接觀察 AIX Kernel 記憶體使用情況：
- 觀察AIX記憶體使用的指令(基于kdb，建議僅在測試環境驗證)
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-02DvYVDR-1613975480770)(https://pic3.zhimg.com/80/v2-a3c4d5b0f3b00607c62bf0ad6179da8e_720w.jpg)]
- 建議
從我們目前實驗的幾個系統看，超過100G的大分區，一般核心的記憶體占用實際都在5%以下。如果 客戶環境中采用了較多第三方驅動或元件，比例可能偏高一些，建議搭建環境驗證一下。
此外，如果系統中存在超大的JFS2檔案系統，包含大量的巨型檔案（比如單個檔案數十、數百GB）， 或者有數以十萬、百萬計的小檔案；則可能觀察到較高的JFS2 中繼資料緩存占用，或者inode緩存 占用。這部分記憶體消耗也會計入AIX kernel，可以通過 cat /proc/sys/fs/jfs2/memory_usage 觀察到:
另，檔案系統的中繼資料緩存和inode緩存可以通過如下ioo參數控制
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-mNoXoki5-1613975480771)(https://pic1.zhimg.com/80/v2-cabacb149c0c2982deef692436d0a51c_720w.jpg)]
這兩個參數是比例系數，設定為400時(AIX6.1預設值)，中繼資料和inode緩存最多能占據系統記憶體的16%左右。一般而言，如果分區記憶體不大或者中繼資料相關操作不多，使用預設值（AIX7.1為200）通常是可 行的。但如果分區記憶體足夠大（比如100GB以上），中繼資料操作較多（可以通過觀察上面的指令 輸出确認），則可以考慮将這兩個參數設定為100，可以使得中繼資料和inode緩存最多占用系統内 存的比例下調至4%左右。
2.9 如何判斷系統是否存在記憶體不足
預期的記憶體需求是 virtual 頁面數加上檔案頁面數（包括 pers 和 clnt），如果這兩者之和大 于實際配置的記憶體頁面數，即可認為存在記憶體不足，如下示例：
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-dAgNzNjZ-1613975480771)(https://pic2.zhimg.com/80/v2-9804dc26293b0d257b2bb4f1bb83c0f9_720w.jpg)]