能测试中AIX服务器资源监控与瓶颈分析-2

2、性能瓶颈定位及实例分析

　　2.1 性能瓶颈定义

　　根据业界的惯例和测试经验，将AIX服务器性能瓶颈定义如下（相关指标项主要参考命令行获取）：

　　2.2 瓶颈分析经验举例

　　经验一：

　　当增大系统压力时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定；若压力增大时，吞吐率（或点击率）的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络带宽出现瓶颈。进行服务器资源瓶颈分析前要先排除网络因素。

　　经验二：

　　资源监控中指标中的内存页交换速率（Paging rate）如果偶尔走高，表明当时有线程竞争内存。如果该项持续在高位，则内存可能是瓶颈。当然此时也可能是内存访问命中率低造成的，要结合“Swap in rate”和“Swap out rate”等指标项进行分析。

　　经验三：

　　指标CPU占用率（CPU utilization）如果持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。服务器CPU合理使用的范围在60%至70%。

　　经验四：

　　指标磁盘交换率（Disk rate）如果一直很高，表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等，另外设置Tempdb in RAM，减低“max async IO”，“max lazy writer IO”等措施都会降低该值。

　　经验五：

　　Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。

　　经验六：

　　SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

　　经验七：

　　交易的响应时间如果很长，远远超过系统性能需求，表示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格 等方法来降低该值。

　　经验八：

　　如果Pages/sec的计数持续高于几百，可能有内存问题。但Pages/sec值不一定就表明有内存问题，可能是运行使用内存映射文件的程 序所致。Page Faults/sec说明每秒发生页面失效次数，页面失效次数越多，说明操作系统向内存读取的次数越多。此事需要查看Pages Read/sec的计数值，该计数器的阀值为5，如果计数值超过5，则可判断存在内存方面的问题。

　　经验九：

　　对Physical Disk计数器的分析包括对Page Reads/sec和%Disk Time及Aerage Disk Queue Length的分析。如果Pages Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时Pages Read/sec并未降低，则是内存不足。

　　经验十：

　　查看System\Processor Queue Length 计数器的值，当该计数器的值大于CPU数量的总数＋1时，说明产生了处理器阻塞。在处理器的%Process Time很高时，一般都随处理器阻塞，但产生处理器阻塞时，Processor\%Process Time 计数器的值并不一定很大，此时就必须查找处理器阻塞的原因。%DOC Time 是另一个需要关注的内容，该计数器越低越好。在多处理器系统中，如果这个值大于50％，并且Processor\%Precessor Time非常高，加入一个网卡可能会提高性能。

　　经验十一：

　　计算每个磁盘的I/O数，每磁盘的I/O数可用来与磁盘的I/O能力进行  对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。如果在Physical Disk 计数器中，只有％Disk Time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80％，则可能是内存泄漏。Disk sec/Transfer小于15ms为Excellent，介于15～30ms之间为良好，30～60ms之间为可以接受，超过60ms则需要考虑更换 硬盘或是硬盘的RAID方式了。

　　3、结论

　　本文在前人总结的基础上，对AIX服务器的资源监控方法进行了总结，并结合自身的测试经验，对瓶颈定位的方法进行了分析。笔者对该问题的总结还不是很完善，希望有关专家提出完善意见。