性能偵探: 哪兒出問題了？
作者：Levitar Pty Ltd
如果您在 IBM AIX 操作系統上遇到某個性能問題，那么您要做的最重要的任務就是正確診斷它。當用戶告訴您 “系統運行緩慢” 時，是時候執行一些偵探工作了。您需要知道應該詢問哪些問題才能幫助您查明真正的問題。本系列由兩部分組成，第一篇文章將演示如何通過描述性能問題來幫助您識別瓶頸。第 2 部分將介紹有助于從一開始就預防這些瓶頸的一些不錯的實踐。
“我們遇到一個問題！”
當系統運行緩慢時，用戶就會尋找快速的解決辦法。有時，快速解決問題的一種誘惑是尋找一個快速修復程序，但該程序可能存在隱藏的癥狀，無法解決真正的底層問題。這不是一種聰明的做法。如果醫生在患者說完他們感覺不適后立即開出處方，您會怎么想？醫藥藝術的核心是診斷。修復系統性能問題也是如此。
詢問正確的問題
您可能需要做大量的調查工作，才能準確找到是什么因素導致響應緩慢。報告的***個癥狀可能并不是惟一的癥狀。它甚至可能不是最嚴重的癥狀。但它對找到何處發生了資源爭用非常重要。這個收集流程可能會花費一些時間，但它可以避免您 “修復” 錯誤的問題，或避免您將時間和精力花在事實上并不重要的癥狀上。
當然，完全修復任何問題的***步是識別問題是什么。要理解為什么響應緩慢，關鍵在于知道查看何處出了問題和詢問出了什么問題。如果您可以將性能問題的詳細描述集中起來，診斷會更容易、更迅速。
隔離問題
如果我必須確定處理性能問題的單一規則，我會說：您必須準確查明您基礎架構中的哪個組件是難點所在。為此，您不但必須查看運行緩慢的組件，還要查看正常運行的組件。
與簡單地假設系統系統綁定了處理器、網絡緩慢或存儲區域網絡 (SAN) 配置較差相比，找到資源爭用區域要有效得多。您會發現，解決一些能揭示基礎架構中的哪個組件可能需要注意的基本問題是很有必要的。
AIX Performance PMR 工具
如果您有一個系統的執行性能低于預期，AIX Performance PMR 數據收集工具可能會為您提供方便（參見 參考資料）。除了提供一些幫助識別資源瓶頸的腳本，Performance PMR 工具 (perfpmr) 還包含一組問題，可幫助您和 IBM 支持人員準確查明性能問題位于何處。通過解決這些問題，您可以更好地掌握真正的瓶頸。
首先，詢問一些基本的問題。到底是什么東西運行緩慢？緩慢的性能影響著一個用戶還是許多用戶？是否是某個進程運行緩慢，比如一個報告、備份或數據庫更新？是否連接到了某個特定的 SAN 獨立磁盤冗余陣列 (RAID) 集的所有系統都響應緩慢？哪個系統受到了影響？哪個應用程序正在運行？是整個 IBM Power systems™ 服務器還是一個邏輯分區 (LPAR) 受到影響？如果是一個 LPAR 受到影響，那么是否是某個文件系統或者甚至一個文件上存在瓶頸？
其他工具
如果將性能問題縮小到一個 LPAR，然后進一步深入研究。您可以通過 df 命令對文件系統的使用情況進行一些基本檢查。nmon 和 topas 等命令可提供邏輯分區的性能的總體視圖。這兩個命令都擁有一些菜單，可深入研究它們來查看處理器的使用情況，識別繁忙的磁盤，顯示網絡統計信息和查看其他許多有用指標的菜單。圖 1 顯示了 topas 命令的主屏幕。
圖 1. topas 命令的主屏幕
vmstat 命令對識別性能瓶頸特別有用。僅這一個命令就可以顯示內存、處理器和 I/O 數據，在下面的 清單 1 中可以看到該命令。
清單 1. 一個 vmstat 示例
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
有關 vmstat 如何快速查明系統中何處在爭用資源的詳細說明，請參閱 “優化 AIX 7 內存性能” 系列。請參閱 參考資料，以獲取與這些和其他與系統性能相關的文章的鏈接。
您能否再現該問題？
當您使用 perfpmr 工具向 IBM 支持人員報告一個性能問題時，如果您可以提供問題的詳細描述，那么這會很有幫助。例如，您可以提供有關該問題的最簡單的可重復示例的更多細節。當您嘗試再現該問題時，查看是否有一個命令或一系列事件始終生成緩慢的結果。AIX 命令的執行是否也很慢？
檢查日志文件
日志文件是一個重要的信息來源。大部分應用程序、數據庫和硬件組件都提供了錯誤日志。如果某個磁帶備份的運行速度異常緩慢，原因可能是磁帶驅動器需要清理。如果磁帶驅動器連接到一個 AIX LPAR，您可以運行 errpt 命令。使用 -a 標志來提供錯誤的詳細描述，如下面的 清單 2 所示。
清單 2. 詳細的錯誤報告 (errpt -a)
# 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
如果有一個腳本運行緩慢，可能它會生成一些輸出來表明它在執行哪個階段。
是否任何內容發生了變化？
當一個運行良好的進程突然運行緩慢，您自然會問，是否有有些內容發生了變化。是否以前（可能在升級之前）正常運行的某個組件不再正常運行？修復不一定是回滾到升級前的配置。可能您需要設置一個調節參數或環境變量。
一個簡單的過程（比如擴展文件系統）可能需要向卷組添加一個新的物理卷。如果新的物理卷具有默認隊列深度屬性，這可能導致 I/O 請求在操作系統上排隊，無論 SAN 能夠多么出色地響應 I/O 請求。
您可以使用 lsattr 命令檢查設備屬性。清單 3 中有一個示例展示了一個物理卷的隊列深度。
清單 3. 列出設備屬性
# lsattr -El hdisk7 -a queue_depth
queue_depth 3 Queue DEPTH True
要更改某個設備屬性，通常可以使用 chdev 命令，如 清單 4 中所示。
清單 4. 更改設備屬性
# chdev -l hdisk7 -a queue_depth=20
hdisk7 changed
如果設備正在使用，您可以釋放可能正在使用它的任何資源或計劃在重新啟動后更改屬性。為此，可以添加 -P 標志（參見下面的 清單 5）。
清單 5. ***更改設備屬性
# chdev -l hdisk7 -a queue_depth=20 -P # Make permanent change
一個正常運行的系統中有非常多的組件，如果您可以確定在出現性能問題之前發生了哪些配置更改，這會為您帶來切實的幫助。
您期望獲得怎樣的性能？
如果是***次設置應用程序、系統或硬件，那么對它們應有的性能預期是否合理？這些預期的依據是什么？例如，是否有一種運行類似進程的等效配置比運行緩慢的配置要快得多？
您可以在兩個 AIX LPAR 上運行 perfpmr 工具，簡單地對比它們。性能數據可提供一種快速度量正常運行的系統應該如何表現的方式。
清單 6 演示了如何在 10 分鐘（600 秒）內運行一個 perfpmr 腳本。輸出的前幾行如下所示。
清單 6. 采集 10 分鐘的性能統計數據
#./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 工具再次提供了一些關鍵問題。性能是間歇性地緩慢還是一直緩慢？緩慢行為是否有一種模式？例如，有時系統似乎時在大量用戶開始登錄時達到性能峰值，但然后會迅速回落。
哪個方面緩慢？
找到到底是什么導致用戶報告系統運行緩慢可能很有用。是登錄所花的時間還是回送一個字符所花的時間？或許某個事務花了太長時間才完成，或者某個報告花了太長時間才生成。
重新啟動是否會臨時修復問題？
如果重新啟動會讓問題消失一會，這可能是由于供其他進程使用的資源未釋放。如果在重新啟動后問題再次出現這個問題，這花了多長時間？有時有必要禁用您懷疑導致響應緩慢的特定進程。
查找可能耗盡內存或處理器時間的進程或具查找有過量 I/O 資源需求的進程總是值得的。ps 命令有許多選項可幫助報告最繁忙的進程。清單 7 就是一個示例。
清單 7. ps 命令報告正在運行的進程
# 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
問題是否與網絡相關？
對于客戶端/服務器配置，可能有必要檢查問題是在服務器本地運行時發生的，還是跨網絡運行時發生的。您可以從控制臺運行應用程序，查看響應時間是否與通過網絡連接時類似。
如果應用程序使用客戶端/服務器模型，您可以使用 ping server_IP_address 從客戶端執行一些基本測試（參見 清單 8）。
清單 8. 按 IP 地址 Ping
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 地址有助于確定問題是否與域名系統 (DNS) 配置相關。如果您懷疑網絡有問題，網絡配置的圖表或描述是一個不錯的出發點。
涉及到哪些供應商應用程序？
一定要知道在性能緩慢的系統上使用了哪些供應商應用程序。您通常應該為一些應用程序使用操作系統調節、建議的內核設置和其他環境變量。可能也有一些可修復應用程序的已知性能問題的補丁。
您應該知道安裝了供應商應用程序的哪些次要版本/主要版本/級別，以及應用程序最近是否更新過。
一般建議
perfpmr 文檔建議提供簡單、具體的問題實例的清楚的書面陳述。它還建議將癥狀和事實與理論、想法和您自己的結論分開。文檔中表明，“如果可以掌握所有的事實情況，那么性能團隊可迅速消除不相關的事實。”
另一個建議是，確保使用了正確的機器來收集信息。在大型站點（尤其是許多虛擬化環境）中，很容易從錯誤的系統收集數據。文檔表明，“這使得分析問題變得很困難。”
要識別機器型號和序列號，您可以使用 lsconf 命令。
當您處理性能問題時，很容易忘記您已采取了哪些步驟來解決問題。記錄采取來診斷或修復問題的操作可以節省大量浪費的工作。
對耐心的回報
修復性能問題需要出色的診斷技能，將事實與理論和假設分開的能力，以及最重要的耐心。解決方案常常很簡單，您的工作會以改進的系統性能作為回報。這個兩部分系列中的下一篇文章將介紹一些實踐，這些實踐可幫助您避免從以開始就發生性能瓶頸。
【編輯推薦】
責任編輯：趙寧寧
