转自公众号@twt社区，作者陈炽卉
3 I/O 监控
3.1 IO 响应时间评估
什么样的 IO 响应时间是合理的？如下是一些经验规则的总结：
- 对于使用机械硬盘、且未配置存储同步镜像的磁阵，评估随机 IO 响应时间的经验规则
- 配置同步镜像时，评估随机 IO 响应时间的经验规则
- 如果使用 SSD 存储
- 对于顺序 IO 而言，不需要担心 IO 服务时间，更应该关注吞吐率；
3.2 通过 nmon 快速定位繁忙的磁盘
进入 nmon 报告的 DISKBUSY 页面，观察 WAvg 的取值。如果 WAvg 在 90%以上，则可能存在 磁盘热点，需要重点监控相关的磁盘。
注意：Avg 显示的平均值是全监控过程的平均（包括磁盘完全 idle 的时段）；而 WAvg 则是 显示在监控时段且磁盘繁忙时的平均；由于 nmon 数据采集周期往往远远长于业务峰值时 间，因此 WAvg 一般比 Avg 更有意义。
如下：
3.3 通过 sar/iostat 命令监控繁忙磁盘
可以通过 sar –d 或 iostat –D 监控繁忙磁盘，如下，其中响应时间以毫秒为单位。一般如果读平均响应时间超过 15ms，写平均响应时间超过 2.5ms，需要重点关注。
排队时间和 sqfull 取值如果长期不为空，则需要判断是否队列深度设置太小(queue_depth)。
说明：为方便脚本分析，一般建议在设置-D 选项同时，加上-l （小写的 L）和-T 选项。这 样对应每个 hdisk 的输出将在同一行显示。
3.4 通过 fcstat 命令监控光纤卡
通过 fcstat 可以观察光纤卡的支持速率和运行速率，例如：
`# fcstat fcs0|grep -i speed
Port Speed (supported): 8 GBIT
Port Speed (running): 8 GBIT`
如果运行的速率低于实际支持的速率，则需要检查交换机与主机的链路状态是否正常。
如果显示如下两个指标持续增长(注意取值肯定是非零值，重点在于增长速度)，则需要相应 的调整光纤卡的 max_xfer_size 和 num_cmd_elems:
或使用fcstat –D判断， num_cmd_elems 的取值应该大于或等于<high water mark of active commands> + <high water mark of pending commands>。比如如下例子中，可以设置 num_cmd_elems 为 180+91= 271.
3.5 使用 filemon 监控 IO 读写情况
可以用 filemon 监控 lf（文件系统），lv（逻辑卷），pv（物理卷），vmm（虚拟内存管理） 层面的信息，如下：
# filemon -T 1000000 -u -O lf,lv,pv,detailed -o fmon.out
# sleep 5
# trcstop
生成的 filemon 报告输出在 fmon.out 里面。
注意：如果报告中出现 xxx events lost，则说明出现了 trace buffer 溢出，可以适当增加 trace buffer （由-T 指定），或者缩短监控周期（从 filemon 到 trcstop 的间隔）。
3.6 阅读 filemon 报告
可以通过 filemon 报告得到最忙的文件、逻辑卷以及物理卷信息，如下：
也可以从 filemon 的 Detailed report 中获得不同文件、逻辑卷、物理卷的读写情况以及响应时间：
其中 seeks 的百分比实际上预示了 IO 的模式，如果 seeks 比例接近 100%，则说明 IO 是随机 型的。反之，如果 seeks 接近 0，则说明 IO 是顺序的。
4 网络监控
4.1 监控网络速率
可以使用 entstat –d entX 命令监控网络速率，以及收发包情况，例如如下场景：
# entstat -d ent0|grep -i speed
Media Speed Selected: Autonegotiate
Media Speed Running: 100 Mbps, Full Duplex
External-Network-Switch (ENS) Port Speed: 100 Mbps, Full Duplex
显示的网络运行速率为 100Mbps；如果实际测试中网络带宽超过 12.5MBps，则说明网络可能是性能瓶颈。
4.2 监控网络响应时间
ping 命令主要用来检查网络的连通性。从 ping 的结果，可以检查网络的质量、丢包率等。Ping 响应的 time 值，可以用来判断两台主机直接的网络传送延时情况，在局域网服务器之 间（大多数为万兆卡光纤连接），time 值应该低于 1ms.
如下提供了一个脚本用于评估两台主机之间的网络延迟：
4.3 监控网卡状态
同时 entstat –d 命令也可以监控到 etherchannel 网卡的流量分布状态（例如收发包以及收发 带宽分布情况），以及 802.3ad 链路的聚合状态，例如，如下示例显示了一个 802.3ad 聚合成功的网卡状态：
4.4 监控网络连接状态
netstat 是用来对网络运行进行统计观察的最常用的一个工具。netstat 有很多参数，主 要用的的有 -in/ -an/ 等等。使用 -in 选项时，需要关注 Ierrs 和 Oerrs 两栏。Ierrs 表示接收失败的总包数，Oerrs 表 示发送失败的总包数。检查 Ierrs/Ipkts 超过 1% 时，或者 Oerrs/Opkts 超过 1% 时，此时 可能要检查一下网络是否存在不稳定的情况。
使用 -an 选项时，注意 Recv-Q、Send-Q 和 state 这三栏。Recv-Q 表示接收网卡队列的排 队情况，Send-Q 表示网卡发送队列的排队情况。state 表示网络连接的状态，一般为 LISTEN 或者 ESTABLISH。当连接长时间处于 LAST_ACK、FIN_WAIT 之类的状态时，说明相关的 TCP 连接状态比较差，如果该 TCP 连接是应用程序所使用，那么需要引起注意。
4.5 查看网络中数据包的重传率
netstat -s 提供了 TCP 的相关统计数据，包括重传统计。TCP 重传会触发拥塞避免算法，造成 网络带宽不能得到有效利用，从而使得性能出现明显下降。尤其是 retransmit timeouts，默认设置下，这类重传超时往往需要 1.5 秒左右，对性能的影响也更为严重。
参考如下 netstat 统计输出，一般如果重传率超过万分之一 ，需要从本机、对端、以及网络 侧（包括交换机、防火墙等等）综合分析丢包的原因，一般需要通过抓包来确认（AIX 上常 用的抓包工具有 iptrace 和 tcpdump）。
4.6 通过 netpmon 监控网络读写情况
通过 aixdemo2 主机向 aixdemo1 主机发起 ftp 传输：
在 aixdemo1 上启动 netpmon 观察：
从 netpmon 的输出中，可以得到各进程 TCP 调用的排序，以及详细分解：
5 自动性能数据收集
1. topasout - - a <*.topas>
2. nmon_analyzer <*.topas.csv>
6 perfpmr 数据收集
下载perfpmr安装包：
根据使用的操作系统版本选择相应的perpmr包，
ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr/
安装perfpmr包：
- 以root权限登录，按bin方式上传perfpmr安装包。
- 创建解压目录
# mkdir /tmp/perf71
# cd /tmp/perf71
3.在/tmp/perf71解压perfpmr安装包
# zcat perf71.tar.Z | tar -xvf -
安装 # sh ./Install
数据收集：
- 创建数据收集目录
# mkdir /tmp/perfdata
# cd /tmp/perfdata
- 运行数据收集命令 -----该命令需要运行5-10分钟。需保证在该命令运行期 间，性能测试一直处于稳定运行状态。'perfpmr.sh 60'
- 取数据 将/tmp/perfdata下的数据打包取回即可；建议使用perfpmr.sh直接打 包（压缩比最优）：在性能数据的上一级目录，运行如下命令：
#perfpmr.sh -o perfdata -z perfdata_<TPS_VALUE>_<GOOD_OR_BAD>.pax.gz