转自公众号@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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。