AIX 5L 記憶體效能優化，第 2 部分:

使用 ps、sar、svmon 和 vmstat 監視記憶體的使用，並分析所得到的結果。這個由三篇文章組成的系列重點關注於在執行 AIX® 的 IBM System p™ 伺服器上進行記憶體管理和優化的各個方面。第 1 部分提供了關於 AIX 中記憶體的概述，包括對虛擬記憶體和虛擬記憶體管理器 (VMM) 的介紹。它還深入地分析了各種優化引數，並對 AIX Version 5.3 中記憶體管理方面的改進內容進行了介紹。第 2 部分重點關注於記憶體子系統監視的詳細內容，並介紹瞭如何分析所得到的結果。第 3 部分主要介紹交換空間，以及如何最好地優化 VMM 設定，以提供最優的交換空間配置和效能。在本系列文章中，我還將介紹一些記憶體效能優化和監視方面的最佳實踐。

引言

記憶體子系統中最重要的優化部分並不涉及到實際的優化工作。在對您的系統進行優化之前，必須弄清楚主機系統的實際執行情況。要做到這一點，AIX® 管理員必須知道應該使用何種工具，以及如何對他或她將要捕獲的資料進行分析。再次說明近期發表的一些其他優化文章（請參見 參考資料）中所介紹的內容，您在對系統進行正確地優化之前，必須首先監視主機，無論它是在邏輯分割槽 (LPAR) 執行還是在自己的物理伺服器上執行。您可以使用許多命令來捕獲和分析資料，所以您需要了解這些命令，以及其中的哪個命令最適合於將要進行的工作。在捕獲了相關的資料之後，您需要對結果進行分析。有些問題乍看起來像是一箇中央處理單元 (CPU) 的問題，而經過分析之後，可以正確地診斷為記憶體或 I/O 問題，前提是您使用了合適的工具捕獲資料，並且知道如何進行分析工作。僅當正確地完成了這些工作之後，您才可以考慮對系統進行實際的更改。如果醫生不瞭解您的病史和目前的症狀，就無法診治疾病，同樣地，您也需要在優化子系統之前對其進行診斷。如果在出現 CPU 或者 I/O 瓶頸的情況下，對記憶體子系統進行優化，這將是毫無幫助的，甚至可能會影響主機的正常執行。

本文將幫助您瞭解正確地實施診斷工作的重要性。您將看到，效能優化並不僅僅只是進行實際的優化工作。在您將要學習的工具中，有一些是通用的監視工具，所有版本的 UNIX 都提供了這些工具，另外還有一些工具是專門為 AIX 編寫的。有些工具為 AIX Version 5.3 進行了優化，同時還專門為 AIX 5.3 系統開發了一些新的工具。

生成基準資料是非常重要的，這一點無論重申多少次都不為過。不要等到使用者開始抱怨糟糕的效能時，才開始監視您的系統。應該在將伺服器投入生產環境中後，儘快地捕獲其中的資料。如果您做到了這一點，那麼您就可以積極主動地進行優化工作，其目標是在使用者指出存在的問題之前找到它。如果您不瞭解系統正常執行時的相關資料，那麼就無法確定所檢視的資料是否表示存在效能問題。所有這些都是適當的效能優化方法中的一部分，有效地捕獲資料，並正確地分析其結果和趨勢。讓我們來進行仔細地研究。

UNIX 通用的記憶體監視

在這個部分中，我為在所有 UNIX 分發版都可以使用的一些通用 UNIX 工具提供了概述，包括 ps、sar 和 vmstat。其中的大多數工具都允許您快速地對效能問題進行故障排除，但是它們並不適合用於進行歷史趨勢研究和分析。

大多數管理員都不善於使用 ps 命令對可能的記憶體瓶頸進行故障排除。事實上，許多 UNIX 管理員甚至不知道可以使用 ps 幫助確定記憶體問題的原因。ps 最常用的功能是檢視系統中執行的程式（請參見清單 1）。

# ps -ef | more
  UID   PID  PPID   C    STIME    TTY  TIME CMD
    root     1     0   0   May 03      -  0:03 /etc/init
    root 11244 19154   0                  0:00 
    root 11384     1   0   May 03      -  0:00 /usr/lib/errdemon
    root 12434 16618   0   May 03      -  0:29 /usr/opt/ifor/bin/i4llmd -b -n wc
clwts -l /var/ifor/llmlg
    root 13218 16618   0   May 03      -  0:00 /usr/sbin/rsct/bin/IBM.AuditRMd
    root 13440     1   0   May 03      -  0:00 /usr/ccs/bin/shlap
    root 13690 13954   0   May 03      -  0:00 dtlogin <:0>        -daemon
    root 13954     1   0   May 03      -  0:00 /usr/dt/bin/dtlogin -daemon

正如您所看到的，上面的示例中並沒有提供很詳細的資訊來幫助您確定記憶體瓶頸。清單 2 中的命令向您顯示了系統中每個活動程式的記憶體使用情況，並以一種恰當的方式進行了排序。其中按照舊式 Berkeley Software Distribution (BSD) 的方式使用了 ps，不包含短橫線。我喜歡這個命令的原因在於，您不需要呼叫任何 GUI 型別的工具，就可以快速地瞭解記憶體方面的情況（請參見清單 2）。

.
# ps gv | head -n 1; ps gv | egrep -v "RSS" | sort +6b -7 -n -r
  PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
 15256      - A    64:15  755  2572  2888    xx  2356   316  0.9  0.0 /usr/lpp/
 22752      - A     0:08  261  1960  1980 32768   465    20  0.0  0.0 dtwm
 14654      - A     0:00  324  1932  1932    xx   198     0  0.0  0.0 /usr/sbin
 20700      - A     0:07  271  1868  1896 32768    95    28  0.0  0.0 /usr/dt/b
 20444      - A     0:03  203  1736  1824 32768   551    88  0.0  0.0 dtfile
 17602      - A     0:00  274   948  1644 32768   817   696  0.0  0.0 sendmail:
 13218      - A     0:00   74  1620  1620    xx   116     0  0.0  0.0 /usr/sbin

讓我們先來看看這些資訊所表示的含義。

• RSS——每個程式的文字和資料段的 RAM 使用量。PID 為 15256 的程式使用了 2888k。
• %MEM——RSS / Total RAM 的實際用量。監視 %MEM 使用達到百分之四十到七十的程式。
• TRS——文字段的 RAM 使用量，單位為 KB。
• SIZE——為這個程式（文字和資料）分配的分頁空間的實際大小。

儘管這個命令提供了許多有價值的資訊，但是，除非有一個我非常信任的管理員已經診斷出系統中存在某種型別的記憶體問題，否則我通常不會啟動這個命令。您應該啟動後備的命令 vmstat。事實上，您應該使用 vmstat 來確定瓶頸的原因，即使在您尚未確定它是否與記憶體有關的時候。vmstat 可以報告許多資訊，包括核心執行緒、CPU 活動、虛擬記憶體、分頁、阻塞的 I/O 磁碟、以及相關資訊（請參見清單 3）。對我來說，要了解系統的執行情況，這是最快捷且最原始的方法。

# vmstat 1 4

System Configuration: lcpu=4 mem=4096MB
kthr     memory             page              faults        cpu
----- ----------- ------------------------ ------------ -----------
 r  b   avm   fre  re   pi  po  fr   sr    cy  in   sy  cs  us sy id wa
 1  2 136583  127    0   4   57  44   92    0 345 2223 605  30 40 29 1
 2  7 136587  118    0   2  230   0   245   0 329 3451 526  20 37 10 33
 1  6 136587  157    0   3   67   0   678   0 334 3304 536  25 32 20 23
 3  8 136587  111    0   5   61   0   693   0 329 3341 511  19 26 35 20

讓我們首先來說明這些列所表示的含義：

記憶體資料：

• avm——您所使用的活動虛擬記憶體量（單位為 4k 大小的頁面），不包括檔案頁面。
• fre——記憶體空閒列表的大小。在大多數情況下，我並不擔心這個值什麼時候變得很小，因為 AIX 總是會充分地使用記憶體，並且不會像您希望的那樣儘早地釋放記憶體。這個設定由 vmo 命令的 minfree 引數來確定。歸根結底，分頁的資訊更加重要。
• pi——從分頁空間調入的頁面。
• po——調出到分頁空間的頁面。

CPU 和 I/O：

• r——在您指定的時間間隔內，可執行核心執行緒的平均數量。
• b——在您指定的時間間隔內，位於虛擬記憶體等待佇列中的核心執行緒的平均數量。如果 r 不大於 b，通常是 CPU 問題的症狀，這可能是由於 I/O 或者記憶體瓶頸造成的。
• us——使用者時間。
• sy——系統時間。
• id——空閒時間。
• wa——等待 I/O。

讓我們回到 vmstat 的輸出，您的系統究竟出現了什麼問題呢？首先是一條免責宣告：請不要根據 vmstat 的簡單輸出結果，向高階管理人員提交詳細的分析和建議採取的優化策略。在正確地診斷出系統中存在的問題之前，您必須完成更多的工作。當您碰到產品效能問題，並且需要立即瞭解系統的執行狀況時，您應該使用 vmstat，以便您可以警告其他人出現了什麼問題，或者馬上採取合適的措施（如果可以）。

現在，再回到輸出。出現了什麼問題呢？實際上，有好幾處問題。初看起來，您可能認為出現了 CPU 瓶頸，因為系統工作得非常辛苦，幾乎沒有什麼空閒時間。如果您仔細地觀察，那麼將會發現，除了 CPU 忙碌工作之外，還存在其他的問題，例如分頁。從 po 可以看出，出現了大量的頁面調出，這種情況通常會在實際記憶體缺乏的時候出現。在輸出結果中，甚至空閒列表也降到非常低的程度。其原因可能因為您的空閒列表 (fre) 比 minfree 的閾值（使用 vmo 進行設定的）要低一些。I/O 方面出現了什麼問題呢？當您發現阻塞的程式或者等待 I/O 的值 (wa) 很高時，這通常表示出現了實際的 I/O 問題，可能是等待檔案訪問、或者與因為系統缺少記憶體而引起的分頁相關的 I/O 狀況。在這個示例中，看起來是後面這種情況。您碰到了 VMM 問題，而這些問題可能導致了阻塞的程式和等待 I/O 的狀況。通過優化記憶體引數、或者執行動態的 LPAR (DLPAR) 操作並向 LPAR 新增更多的 RAM，您可以解決這個問題。

讓我們進行更深入的研究。您可以使用前面介紹過的 ps 命令來嘗試確定影響系統的程式。通常在這種情況下，我會執行 sar 以檢查該問題是否在使用另一種工具進行分析時依然存在。最好是使用多種工具，以便提供進一步的幫助，從而確保診斷結果是正確的。

儘管與其他工具相比，我並不是很喜歡 sar（因為您需要使用許多的標誌，並且在診斷問題之前必須輸入許多的命令），但是，它允許您實時地收集資料，並檢視所捕獲的資料（使用 sadc）。大多數較早的工具都允許您使用不同的命令。自從有了 UNIX，就有了 sar 命令，並且每個人都曾經用過這個命令。使用 -r 標誌可以提供一些 VMM 資訊（請參見清單 4）。

# sar -r 1 5
System Configuration: lcpu=4 mem=4096MB

06:18:05   slots  cycle/s  fault/s  odio/s
06:18:06 1048052    0.00    387.25   0.00
06:18:07 1048052    0.00    112.97   0.00
06:18:08 1048052    0.00    45.00   79.21
06:18:09 1048052    0.00    216.00    0.00
06:18:10 1048052    0.00    8.00      0.00

Average  1048052        0      79      16

那麼，這個結果究竟意味著什麼呢？

• cycle/s——報告每秒的頁面置換週期數。
• fault/s——提供每秒的缺頁次數。
• Slots——提供分頁空間中空閒頁面的數目。
• odio/s——提供每秒的非分頁磁碟 I/O 次數。

在這個示例中，您可以看到每秒鐘有許多次的缺頁，但是其他的值並不大。您還可以看到，分頁空間中有 1048052 個 4k 的頁面可用，總計約 4GB。下面，讓我們再來深入地研究特定 AIX 工具的使用。

特定的 AIX 記憶體監視

在這個部分中，我提供了關於可用的特定 AIX 工具的概述，包括 svmon、procmon、topas 和 nmon。其中的大多數工具都允許您快速地進行故障排除，並獲取相關的資料以便進行歷史趨勢研究和分析。

svmon 是一種分析實用工具。它專門針對於 VMM。它可以提供許多資訊，包括所使用的實際、虛擬和分頁空間記憶體。-G 標誌可以為主機中的記憶體使用情況提供全域性的檢視（請參見清單 5）。

# svmon -G
               size      inuse       free        pin    virtual
memory      1048576    1048416        160      79327     137750
pg space    1048576        524

               work       pers       clnt      lpage
pin           79327          0          0          0
in use       137764     910652          0          0

其中的 size 列報告了 RAM 的大小，單位是大小為 4k 的頁面。其中的 inuse 列報告了程式所使用的 RAM 中的頁面數，加上屬於一個已終止的程式但仍位於 RAM 中的持久頁面的數目。其中的 free 列報告了空閒列表中頁面的數目。其中的 pin 列報告了實體記憶體 (RAM) 中固定的頁面數。固定的頁面不能被調出。

paging space 列報告了分頁空間的實際使用情況（單位是大小為 4k 的頁面）。重要的是，應該清楚這個結果與 vmstat 所報告的結果之間的區別。vmstat 中的 avm 列顯示了訪問的所有虛擬記憶體，即使它沒有被調出。我還習慣檢視工作和持久頁面的數目。這些引數顯示了 RAM 中工作和持久頁面的數目。這個內容為什麼非常重要呢？也許您還記得第 1 部分中的內容，我曾介紹了工作和持久儲存之間的區別。當您的程式對計算資訊進行處理時，將使用到計算記憶體。它們使用工作段，而這些工作段是臨時的（暫時的），並且當程式終止或者頁面被替換時，這些工作段將不復存在。檔案記憶體使用持久段，並在磁碟上具有持久的儲存位置。資料檔案或者可執行程式通常都對映為持久段，而不是工作段。在可以選擇的情況下，您更希望將檔案記憶體調出到磁碟，而不是計算記憶體。在這種情況下，與檔案記憶體相比，計算記憶體更有可能被調出。也許，對 vmo 引數稍作優化就可以極大提高系統的效能。svmon 的另一個有價值的特性是，您可以顯示給定程式的記憶體統計資訊。清單 6 提供了一個示例。

# svmon -P | grep -p 15256
-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd LPage
   15256 X                12102     3221        0    12022      N     N     N

從這個示例中，您可以確定該程式並沒有使用分頁空間。使用前面介紹過的 ps 命令，再加上 svmon，您就可以找出大量消耗記憶體資源的位置。

讓我們使用一種對使用者來說更加友好的工具，topas。topas 是一種非常優秀的小型效能監視工具，它可以用於許多目的（請參見 圖 1）。

正如您所看到的，執行 topas 將為您提供一個有關程式資訊、CPU、I/O 和 VMM 活動的列表。從這個列表中，您可以看到該系統僅使用了很少的分頁空間。我常常使用這個命令快速地進行故障排除，特別是當我希望在螢幕上顯示比 vmstat 更詳細的內容時。我將 topas 看作是 vmstat 的圖形化版本。在經過改進之後，現在它可以捕獲資料以進行歷史分析。

procmon 命令又如何呢？它在 AIX Version 5.3 中首次引入，不僅可以提供整體 CPU 效能統計，還允許您對實際執行的程式進行相應的操作。您可能已經瞭解，可以動態地對一個程式使用 kill 或者 renice 命令，但我敢打賭，您肯定不清楚如何深入地研究有關記憶體的內容。

儘管我認為人們通常使用這個工具進行 CPU 分析，但是它也為 svmon 提供了很好的掛鉤，以便在緊要關頭為您提供幫助。這個檢視可以為從 procmon 中使用 svmon 實用工具設定相關的選項，它允許您以一種更合適的格式提取資訊（請參見圖 2）。

您還可以將 procmon 資料匯出到一個檔案，這使得它成為一種優秀的資料收集工具。

在所有的效能工具中，我最喜歡的是一種不受支援的 IBM 工具，名為 nmon。它在某些方面與 topas 類似，nmon 收集到的資料可以顯示在螢幕上（類似於 topas）或者通過報告提供（您可以捕獲相關的資訊以進行趨勢研究和分析）。這個工具提供了一些其他工具所沒有的功能，它可以在 Microsoft® Excel 電子表格中顯示美觀的圖表，可以將其交給高階管理人員或者其他技術團隊進行更深入地分析。可以使用另一種不受支援的工具，名為 nmon analyzer，它為 nmon 提供了相應的掛鉤。圖 3 顯示了 nmon 分析結果的一個示例。

在使用這個工具的過程中，您將看到 nmon 所提供的許多不同型別的檢視，這些檢視可以提供所有關於 CPU、I/O 和記憶體的使用資訊。

總結

在本文中，您瞭解了可用於捕獲資料以進行記憶體分析的各種工具。您還學習瞭如何對存在效能問題的系統進行故障排除，您可以對虛擬記憶體進行控制。優化工作實際上只是適當的優化方法中的一小部分，對於這一點，重申多少次都不為過。如果不能夠捕獲資料並仔細地、正確地分析您的系統，那麼您所能做的工作就好像是一名醫生根本不對患者進行檢查就胡亂地使用抗生素藥物。

您可以使用許多不同型別的效能監視工具。有些工具可以從命令列中執行，以便快速地檢查系統的執行情況。有些工具更適合於進行長期的趨勢研究和分析。有些工具甚至可以為您提供圖形格式的資料，可以將這些資料交給非技術方面的工作人員。無論您使用哪種工具，都還必須仔細地瞭解您所檢視的資訊的真正含義。不要只根據少量的資料樣本，就急於得出結論。另外，不要僅依賴於某一種工具。為了證實您的結論，在進行分析時，您應該至少使用兩種不同的工具。我還簡要地介紹了優化方法和建立系統正常執行時的基準資料的重要性。在您檢查資料並實施優化之後，您必須繼續捕獲資料，並分析所作更改的結果。而且，您應該一次只進行一處更改，這樣才能夠真正地確定每項更改的效果。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9390331/viewspace-703194/，如需轉載，請註明出處，否則將追究法律責任。