“我们遇到一个问题！”
当系统运行缓慢时，用户就会寻找快速的解决办法。有时，快速解决问题的一种诱惑是寻找一个快速修复程序，但该程序可能存在隐藏的症状，无法解决真正的底层问题。这不是一种聪明的做法。如果医生在患者说完他们感觉不适后立即开出处方，您会怎么想？医药艺术的核心是诊断。修复系统性能问题也是如此。
询问正确的问题
您可能需要做大量的调查工作，才能准确找到是什么因素导致响应缓慢。报告的***个症状可能并不是惟一的症状。它甚至可能不是最严重的症状。但它对找到何处发生了资源争用非常重要。这个收集流程可能会花费一些时间，但它可以避免您 “修复” 错误的问题，或避免您将时间和精力花在事实上并不重要的症状上。
当然，完全修复任何问题的***步是识别问题是什么。要理解为什么响应缓慢，关键在于知道查看何处出了问题和询问出了什么问题。如果您可以将性能问题的详细描述集中起来，诊断会更容易、更迅速。
隔离问题
如果我必须确定处理性能问题的单一规则，我会说：您必须准确查明您基础架构中的哪个组件是难点所在。为此，您不但必须查看运行缓慢的组件，还要查看正常运行的组件。
与简单地假设系统系统绑定了处理器、网络缓慢或存储区域网络 (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 命令。
当您处理性能问题时，很容易忘记您已采取了哪些步骤来解决问题。记录采取来诊断或修复问题的操作可以节省大量浪费的工作。
对耐心的回报
修复性能问题需要出色的诊断技能，将事实与理论和假设分开的能力，以及最重要的耐心。解决方案常常很简单，您的工作会以改进的系统性能作为回报。这个两部分系列中的下一篇文章将介绍一些实践，这些实践可帮助您避免从以开始就发生性能瓶颈。
【编辑推荐】
