监控服务器资源定位性能瓶颈,五步定位性能瓶颈

3.4 网络I/O

很多时候大家都容易忽略网络对系统的影响，实际上网络带宽在一些情况下也会成为系统的瓶颈。一旦在业务的请求和响应中包含较大的数据传输时，往往会遇到网络瓶颈。因为更多的时候服务器采用的还是以太网卡，1000M网卡在全双工模式下传输速率也只有80M/s，如果响应中包含报表、图片之类的大尺寸数据，很有可能在性能测试中出现网络瓶颈。

还有一点就是不要忽略回环地址传输的影响，比如一些应用访问本地监听的其他服务，都会受到网卡的传输速率限制的影响。

4、软件性能软肋：数据库的监控分析

对于Web系统，超过七成的瓶颈都出现在数据库子系统，因此在进行之前几步不能明确瓶颈位置的时候，应优先进行数据库的监控分析。

Oracle数据库监控工具

Oracle本身提供了ASH，AWR等Report来帮助进行性能分析，但是对于测试人员来说，掌握这些需要较深入的数据库知识学习，不是一朝一夕可以达成的。而一些第三方提供的工具，通过图形界面，可以更加直观的帮助我们进行Oracle数据库的监控和分析。

Lab128就是国内开发的一块很不错的共享软件，而且它还提供无限期的试用key，可以免费试用。

Oracle中的等待事件

判断Oracle中的瓶颈，了解Oracle中的等待事件Wait event，对于查找瓶颈有很大的帮助。在Oracle中，处理SQL的过程，会产生一系列的等待事件。

有等待事件并不代表数据库存在瓶颈，正常的处理也会有等待事件，但如果发现等待事件激增，或者SQL执行缓慢，这时候等待事件中排名靠前的事件将会直接反映出瓶颈所在。

上图是在测试中的某一时刻，log sync的等待事件突然增高，同时数据库的吞吐率大幅下降，原本正常的SQL执行速度也突然变长。

因为压力并没有突然改变，很有可能是写log的过程出现了问题，或者是在传输过程，或者是在存储子系统。后来经过排查，发现是存储集群的一个存储单元出现故障导致写入速度变慢致使出现大量等待。

5、最后的大杀器：应用服务器监控及代码分析

如果没能在其他位置发现瓶颈，那么软件程序所运行的平台——应用服务器很可能是最大的潜在瓶颈点，进行应用服务器的监控与分析将是我们最后的大杀器。

5.1 常见的软件资源种类

相对于硬件资源，软件资源往往容易被忽略，它不像CPU占用率那么让人更直观的和性能联系起来，但是实际上，软件资源同样限制着软件系统能达到什么样的性能。

软件资源不论是在Web层，应用层还是在数据库层，都可以按“入口”、“内部”、“出口”来划分。对于常见的原因中间件，“入口”就是如HTTP连接池之类，是数据来源方向的相关设置，比如连接数限制，超时时间，连接回收策略等等；“内部”就是处理请求的各项资源，不如线程数，线程调度策略，虚拟内存设置，GC策略等等；“出口”则是向后端交互的各项资源，如数据库连接池的配置。

5.2 应用中间件监控

要了解软件资源是否成为瓶颈，我们就需要监控这些软件资源指标。以JAVA环境为例，Weblogic 本身就有控制台，提供了各种计数器。

上图显示的是Execute Threads的计数器，对请求的处理就在这些Thread中进行。

Tomcat也有开源的控制台，常用的像PSI-Probe，提供了Tomcat服务器各项资源的图形化监控。如下图中对JVM的监控。

5.3 应用中间件剖析

仅仅监控只能初步判断问题的方向，例如发现ExecuteThreads持续的增加，我们虽然知道这个现象不正常，但是想要确定是程序中的哪个方法导致了当前问题，我还需要其他的工具进行深入剖析。

对于Java程序，最常用的工具有JProfiler，YourKit，他们的原理类似，都是要把一个小插件挂在到应用服务器上，以获取需要的程序运行信息。

而Sun在JDK1.7后版本整合了继承自JRockit的MissionControl，也提供了很强大的分析监控功能，而且开销较小，确实是个不错的选择。

它提供的Mem leak detector可以对对象的创建进行趋势分析，帮你找到最有可能出现泄漏的对象，

再通过展开剖析工具中的invoke tree，找出创建该对象的方法，可以更细致的定位问题的原因。

同时，Call tree 也可以依据CPU时间进行分析，找到在虚拟机中消耗最高的方法。

22/2<12