您可能需要做大量的調(diào)查工作，才能準(zhǔn)確找到是什么因素導(dǎo)致響應(yīng)緩慢。報告的***個癥狀可能并不是惟一的癥狀。它甚至可能不是最嚴(yán)重的癥狀。但它對找到何處發(fā)生了資源爭用非常重要。這個收集流程可能會花費一些時間，但它可以避免您 “修復(fù)” 錯誤的問題，或避免您將時間和精力花在事實上并不重要的癥狀上。

當(dāng)然，完全修復(fù)任何問題的***步是識別問題是什么。要理解為什么響應(yīng)緩慢，關(guān)鍵在于知道查看何處出了問題和詢問出了什么問題。如果您可以將性能問題的詳細(xì)描述集中起來，診斷會更容易、更迅速。

 

如果我必須確定處理性能問題的單一規(guī)則，我會說：您必須準(zhǔn)確查明您基礎(chǔ)架構(gòu)中的哪個組件是難點所在。為此，您不但必須查看運行緩慢的組件，還要查看正常運行的組件。

與簡單地假設(shè)系統(tǒng)系統(tǒng)綁定了處理器、網(wǎng)絡(luò)緩慢或存儲區(qū)域網(wǎng)絡(luò) (SAN) 配置較差相比，找到資源爭用區(qū)域要有效得多。您會發(fā)現(xiàn)，解決一些能揭示基礎(chǔ)架構(gòu)中的哪個組件可能需要注意的基本問題是很有必要的。

如果您有一個系統(tǒng)的執(zhí)行性能低于預(yù)期，AIX Performance PMR 數(shù)據(jù)收集工具可能會為您提供方便（參見 參考資料）。除了提供一些幫助識別資源瓶頸的腳本，Performance PMR 工具 (perfpmr) 還包含一組問題，可幫助您和 IBM 支持人員準(zhǔn)確查明性能問題位于何處。通過解決這些問題，您可以更好地掌握真正的瓶頸。

首先，詢問一些基本的問題。到底是什么東西運行緩慢？緩慢的性能影響著一個用戶還是許多用戶？是否是某個進程運行緩慢，比如一個報告、備份或數(shù)據(jù)庫更新？是否連接到了某個特定的 SAN 獨立磁盤冗余陣列 (RAID) 集的所有系統(tǒng)都響應(yīng)緩慢？哪個系統(tǒng)受到了影響？哪個應(yīng)用程序正在運行？是整個 IBM Power systems™ 服務(wù)器還是一個邏輯分區(qū) (LPAR) 受到影響？如果是一個 LPAR 受到影響，那么是否是某個文件系統(tǒng)或者甚至一個文件上存在瓶頸？

 

如果將性能問題縮小到一個 LPAR，然后進一步深入研究。您可以通過 df 命令對文件系統(tǒng)的使用情況進行一些基本檢查。nmon 和 topas 等命令可提供邏輯分區(qū)的性能的總體視圖。這兩個命令都擁有一些菜單，可深入研究它們來查看處理器的使用情況，識別繁忙的磁盤，顯示網(wǎng)絡(luò)統(tǒng)計信息和查看其他許多有用指標(biāo)的菜單。圖 1 顯示了 topas 命令的主屏幕。

 

 

vmstat 命令對識別性能瓶頸特別有用。僅這一個命令就可以顯示內(nèi)存、處理器和 I/O 數(shù)據(jù)，在下面的 清單 1 中可以看到該命令。

 

 

 

vmstat 1 4

 

System configuration: lcpu=12 mem=7168MB ent=2.80

 

kthr    memory              page              faults              cpu

----- ----------- ------------------------ ------------ -----------------------

 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc    ec

 5  0 793201 942484   0   0   0   0    0   0 15550 32034 25717  4 37 50  8  1.32  47.1

 1  0 793201 942484   0   0   0   0    0   0 17369 36882 29660  6 40 48  6  1.45  51.6

 0  0 793201 942484   0   0   0   0    0   0 18309 39566 33628  8 39 47  7  1.45  51.9

 4  0 793203 942482   0   0   0   0    0   0 16068 34022 27586  5 39 49  6  1.40  49.8

 

 

有關(guān) vmstat 如何快速查明系統(tǒng)中何處在爭用資源的詳細(xì)說明，請參閱 “優(yōu)化 AIX 7 內(nèi)存性能” 系列。請參閱 參考資料，以獲取與這些和其他與系統(tǒng)性能相關(guān)的文章的鏈接。

當(dāng)您使用 perfpmr 工具向 IBM 支持人員報告一個性能問題時，如果您可以提供問題的詳細(xì)描述，那么這會很有幫助。例如，您可以提供有關(guān)該問題的最簡單的可重復(fù)示例的更多細(xì)節(jié)。當(dāng)您嘗試再現(xiàn)該問題時，查看是否有一個命令或一系列事件始終生成緩慢的結(jié)果。AIX 命令的執(zhí)行是否也很慢？

 

日志文件是一個重要的信息來源。大部分應(yīng)用程序、數(shù)據(jù)庫和硬件組件都提供了錯誤日志。如果某個磁帶備份的運行速度異常緩慢，原因可能是磁帶驅(qū)動器需要清理。如果磁帶驅(qū)動器連接到一個 AIX LPAR，您可以運行 errpt 命令。使用 -a 標(biāo)志來提供錯誤的詳細(xì)描述，如下面的 清單 2 所示。

 

 

# errpt -a | more

LABEL:          TAPE_ERR1

IDENTIFIER:     4865FA9B

 

Date/Time:       Sat Oct  1 12:56:00 AEST 2011

Sequence Number: 136509

Machine Id:      00C***47E4C00

Node Id:         tsm1

Class:           H

Type:            PERM

WPAR:            Global

Resource Name:   rmt1

Resource Class:

Resource Type:

Location:

VPD:

        Manufacturer................IBM

        Machine Type and Model......ULT3580-TD3

        Serial Number...............1210002439

        Device Specific.(FW)........93G6

 

Description

TAPE OPERATION ERROR

 

如果有一個腳本運行緩慢，可能它會生成一些輸出來表明它在執(zhí)行哪個階段。

 

當(dāng)一個運行良好的進程突然運行緩慢，您自然會問，是否有有些內(nèi)容發(fā)生了變化。是否以前（可能在升級之前）正常運行的某個組件不再正常運行？修復(fù)不一定是回滾到升級前的配置。可能您需要設(shè)置一個調(diào)節(jié)參數(shù)或環(huán)境變量。

一個簡單的過程（比如擴展文件系統(tǒng)）可能需要向卷組添加一個新的物理卷。如果新的物理卷具有默認(rèn)隊列深度屬性，這可能導(dǎo)致 I/O 請求在操作系統(tǒng)上排隊，無論 SAN 能夠多么出色地響應(yīng) I/O 請求。

您可以使用 lsattr 命令檢查設(shè)備屬性。清單 3 中有一個示例展示了一個物理卷的隊列深度。

 

 

 

# lsattr -El hdisk7 -a queue_depth

queue_depth 3  Queue DEPTH True

 

要更改某個設(shè)備屬性，通常可以使用 chdev 命令，如 清單 4 中所示。

 

 

 

# chdev -l hdisk7 -a queue_depth=20

hdisk7 changed

 

如果設(shè)備正在使用，您可以釋放可能正在使用它的任何資源或計劃在重新啟動后更改屬性。為此，可以添加 -P 標(biāo)志（參見下面的 清單 5）。

 

 

 

# chdev -l hdisk7 -a queue_depth=20 -P   # Make permanent change

 

一個正常運行的系統(tǒng)中有非常多的組件，如果您可以確定在出現(xiàn)性能問題之前發(fā)生了哪些配置更改，這會為您帶來切實的幫助。

 

如果是***次設(shè)置應(yīng)用程序、系統(tǒng)或硬件，那么對它們應(yīng)有的性能預(yù)期是否合理？這些預(yù)期的依據(jù)是什么？例如，是否有一種運行類似進程的等效配置比運行緩慢的配置要快得多？

您可以在兩個 AIX LPAR 上運行 perfpmr 工具，簡單地對比它們。性能數(shù)據(jù)可提供一種快速度量正常運行的系統(tǒng)應(yīng)該如何表現(xiàn)的方式。

清單 6 演示了如何在 10 分鐘（600 秒）內(nèi)運行一個 perfpmr 腳本。輸出的前幾行如下所示。

 

 

 

#./perfpmr.sh 600

 

(C) COPYRIGHT International Business Machines Corp., 2000,2001,2002,2003,2004-2008

 

23:12:26-10/05/11 :     perfpmr.sh begin

    PERFPMR: hostname: slowhost

    PERFPMR: perfpmr.sh Version 610 2010/12/01

 

 

在這里，perfpmr 工具再次提供了一些關(guān)鍵問題。性能是間歇性地緩慢還是一直緩慢？緩慢行為是否有一種模式？例如，有時系統(tǒng)似乎時在大量用戶開始登錄時達(dá)到性能峰值，但然后會迅速回落。

找到到底是什么導(dǎo)致用戶報告系統(tǒng)運行緩慢可能很有用。是登錄所花的時間還是回送一個字符所花的時間？或許某個事務(wù)花了太長時間才完成，或者某個報告花了太長時間才生成。

如果重新啟動會讓問題消失一會，這可能是由于供其他進程使用的資源未釋放。如果在重新啟動后問題再次出現(xiàn)這個問題，這花了多長時間？有時有必要禁用您懷疑導(dǎo)致響應(yīng)緩慢的特定進程。

查找可能耗盡內(nèi)存或處理器時間的進程或具查找有過量 I/O 資源需求的進程總是值得的。ps 命令有許多選項可幫助報告最繁忙的進程。清單 7 就是一個示例。

 

 

# ps -ef | more

    UID      PID     PPID   C    STIME    TTY  TIME CMD

    root        1        0   0   Oct 04      -  0:01 /etc/init

    root   655466  3866772   0   Oct 04      -  0:00 /usr/sbin/snmpd

    root  2097342        1   0   Oct 04      -  0:00 /bin/ksh /usr/tivoli/tsm/server/bin/

rc.adsmserv

    root  2424972  3866772   0   Oct 04      -  0:00 /usr/sbin/inetd

    root  2883806        1   0   Oct 04      -  0:00 /usr/lib/errdemon

    root  2949246        1   0   Oct 04      -  0:00 /usr/ccs/bin/shlap64

    root  3276878  3866772   0   Oct 04      -  0:00 /usr/sbin/syslogd

    root  3604516        1   0   Oct 04      -  1:24 /usr/sbin/syncd 60

    root  3670082  3866772   0   Oct 04      -  0:05 /usr/sbin/xntpd

    root  3735676  3866772   0   Oct 04      -  0:00 /usr/sbin/muxatmd

    root  3801210  3866772   0   Oct 04      -  0:00 /usr/sbin/hostmibd

    root  3866772        1   0   Oct 04      -  0:00 /usr/sbin/srcmstr

    root  3932286  3866772   0   Oct 04      -  0:00 /usr/sbin/portmap

    root  3997832  3866772   0   Oct 04      -  0:00 /usr/sbin/aixmibd

    root  4063420        1   0   Oct 04      -  0:44 /usr/sbin/getty /dev/consol

e

    root  4128936  3866772   0   Oct 04      -  0:03 sendmail: accepting connect

ions

    root  4259980  3866772   0   Oct 04      -  0:00 /usr/sbin/snmpmibd

    root  4325556        1   0   Oct 04      -  0:02 /usr/sbin/cron

    root  4391124  3866772   0   Oct 04      -  0:03 /usr/sbin/rsct/bin/vac8/IBM.

CSMAgentRMd

    root  4522176        1   0   Oct 04      -  0:00 /usr/bin/dsmcad

    root  4718774  3866772   0   Oct 04      -  0:00 /usr/sbin/rpc.lockd -d 0

    root  4784284  2424972   0   Oct 04      -  1:10 xmtopas -p3

    root  4980888  3866772   0   Oct 04      -  0:00 /usr/sbin/biod 6

    root  5177506  3866772   0   Oct 04      -  0:00 /usr/sbin/nfsd 3891

    root  5243046  3866772   0   Oct 04      -  0:00 /usr/sbin/rpc.mountd

    root  5439672  3866772   0   Oct 04      -  0:04 /usr/sbin/rsct/bin/rmcd -a IBM.

LPCommands -r

    root  5570560        1   0   Oct 04      -  0:00 bin/nonstop_aix @config/nonstop.

properties

    root  5701822  2097342 208   Oct 04      - 938:56 dsmserv quiet

    root  5832888        1   0   Oct 04      -  0:02 /usr/local/sbin/sshd

    root  5898436  3866772   0   Oct 04      -  0:00 /usr/sbin/qdaemon

    root  5963972        1   0   Oct 04      -  0:00 /usr/sbin/uprintfd

    root  6095040  3866772   0   Oct 04      -  0:00 /usr/sbin/writesrv

    root  6160590  3866772   0   Oct 04      -  0:08 /usr/sbin/pcmsrv

    root  6291682  3866772   0   Oct 04      -  0:00 /usr/sbin/rsct/bin/IBM.DRMd

 

對于客戶端/服務(wù)器配置，可能有必要檢查問題是在服務(wù)器本地運行時發(fā)生的，還是跨網(wǎng)絡(luò)運行時發(fā)生的。您可以從控制臺運行應(yīng)用程序，查看響應(yīng)時間是否與通過網(wǎng)絡(luò)連接時類似。

如果應(yīng)用程序使用客戶端/服務(wù)器模型，您可以使用 ping server_IP_address 從客戶端執(zhí)行一些基本測試（參見 清單 8）。

 

 

ping 192.168.168.30

PING 192.168.168.30: (192.168.168.30): 56 data bytes

64 bytes from 192.168.168.30: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 192.168.168.30: icmp_seq=1 ttl=255 time=0 ms

64 bytes from 192.168.168.30: icmp_seq=2 ttl=255 time=0 ms

64 bytes from 192.168.168.30: icmp_seq=3 ttl=255 time=0 ms

 

----192.168.168.30 PING Statistics----

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max = 0/0/0 ms

 

ping IP 地址有助于確定問題是否與域名系統(tǒng) (DNS) 配置相關(guān)。如果您懷疑網(wǎng)絡(luò)有問題，網(wǎng)絡(luò)配置的圖表或描述是一個不錯的出發(fā)點。

一定要知道在性能緩慢的系統(tǒng)上使用了哪些供應(yīng)商應(yīng)用程序。您通常應(yīng)該為一些應(yīng)用程序使用操作系統(tǒng)調(diào)節(jié)、建議的內(nèi)核設(shè)置和其他環(huán)境變量。可能也有一些可修復(fù)應(yīng)用程序的已知性能問題的補丁。

您應(yīng)該知道安裝了供應(yīng)商應(yīng)用程序的哪些次要版本/主要版本/級別，以及應(yīng)用程序最近是否更新過。

 

perfpmr 文檔建議提供簡單、具體的問題實例的清楚的書面陳述。它還建議將癥狀和事實與理論、想法和您自己的結(jié)論分開。文檔中表明，“如果可以掌握所有的事實情況，那么性能團隊可迅速消除不相關(guān)的事實。”

另一個建議是，確保使用了正確的機器來收集信息。在大型站點（尤其是許多虛擬化環(huán)境）中，很容易從錯誤的系統(tǒng)收集數(shù)據(jù)。文檔表明，“這使得分析問題變得很困難。”

要識別機器型號和序列號，您可以使用 lsconf 命令。

當(dāng)您處理性能問題時，很容易忘記您已采取了哪些步驟來解決問題。記錄采取來診斷或修復(fù)問題的操作可以節(jié)省大量浪費的工作。

 

修復(fù)性能問題需要出色的診斷技能，將事實與理論和假設(shè)分開的能力，以及最重要的耐心。解決方案常常很簡單，您的工作會以改進的系統(tǒng)性能作為回報。這個兩部分系列中的下一篇文章將介紹一些實踐，這些實踐可幫助您避免從以開始就發(fā)生性能瓶頸。

 

原文鏈接：http://www.ibm.com/developerworks/cn/aix/library/au-performancedectective/index.html?cmp=dwskl&cpb=dw&ct=dwcon&cr=cn_swb&ccy=cn