性能瓶颈分析方法

 同一场景

1.小用户量的状况下测试
2.大用户量状况下的测试
分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，经过事务摘要图分析事务响应时间，哪一个消耗最大（经过小用户量和大用户量的响应时间分析，查看哪一个事务响应时间最高），肯定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu
使用下列计数器标识cpu瓶颈

• 　　Processor\ Interrupts/sec
• 　　Processor\ % Processor Time
• 　　Process(process)\ % Processor Time
• 　　System\ Processor Queue Length

经过它来肯定是否硬件自己出现瓶颈，或者进一步肯定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有不少种状况须要你本身去判断，有多是进程调用了的函数消耗了系统资源造成上边的问题，也有多是后台数据库出现的问题（这个就要看你的系统配置是什么样的，好比你的db服务器和应用服务器都配置在一台机器上）
性能产生瓶颈有不少地方，因此须要进一判断，是不是后台数据库的问题还有待分析，是那条语句致使的问题须要进一步分析判断。
分析原则：
• 具体问题具体分析（这是因为不一样的应用系统，不一样的测试目的，不一样的性能关注点）
• 查找瓶颈时按如下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，能够不考虑）-〉服务器操做系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并非每一个分析中都须要的，要根据测试目的和要求来肯定分析的深度。对一些要求低的，咱们分析到应用系统在未来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法颇有效

分析的信息来源：

• 根据场景运行过程当中的错误提示信息
• 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

• Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
• Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

分析：
A、应用服务死掉。
   （小用户时：程序上的问题。程序上处理数据库的问题）
B、应用服务没有死
   （应用服务参数设置问题）
    例：在许多客户端链接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有多是Weblogic中的server元素的 AcceptBacklog属性值设得太低。若是链接时收到      connection refused消息，说明应提升该值，每次增长25％
C、数据库的链接
     (一、在应用服务的性能参数可能过小了 二、数据库启动的最大链接数（跟硬件的内存有关）)

• Error: Page download timeout (120 seconds) has expired

分析：多是如下缘由形成
A、应用服务参数设置太大致使服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，若是出现了大于3个用户的业务操做失败，或出现了服务器shutdown的状况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
若是测得的最大并发用户数到达了性能要求，且各服务器资源状况良好，业务操做响应时间也达到了用户要求，那么OK。不然，再根据各服务器的资源状况和业务操做响应时间进一步分析缘由所在。
2．业务操做响应时间：
• 分析方案运行状况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，能够肯定在方案执行期间响应时间过长的事务。
• 细分事务并分析每一个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引发的？问题是否与网络或服务器有关？
• 若是服务器耗时过长，请使用相应的服务器图肯定有问题的服务器度量并查明服务器性能降低的缘由。若是网络耗时过长，请使用“网络监视器”图肯定致使性能瓶颈的网络问题
3．服务器资源监控指标：
内存：

1. UNIX资源监控中指标内存页交换速率（Paging rate），若是该值偶尔走高，代表当时有线程竞争内存。若是持续很高，则内存多是瓶颈。也多是内存访问命中率低。
2. Windows资源监控中，若是Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续下降，则极可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

• • 很高的换页率(high pageout rate);
  • 进程进入不活动状态;
  • 交换区全部磁盘的活动次数可高;
  • 可高的全局系统CPU利用率;
  • 内存不够出错(out of memory errors)

处理器：

1. UNIX资源监控（Windows操做系统同理）中指标CPU占用率（CPU utilization），若是该值持续超过95%，代表瓶颈是CPU。能够考虑增长一个处理器或换一个更快的处理器。若是服务器专用于SQL Server,可接受的最大上限是80-85%
2. 合理使用的范围在60%至70%。
3. Windows资源监控中，若是System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:

• • 很慢的响应时间(slow response time)
  • CPU空闲时间为零(zero percent idle CPU)
  • 太高的用户占用CPU时间(high percent user CPU)
  • 太高的系统占用CPU时间(high percent system CPU)
  • 长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1. UNIX资源监控（Windows操做系统同理）中指标磁盘交换率（Disk rate），若是该参数值一直很高，代表I/O有问题。可考虑更换更快的硬盘系统。
2. Windows资源监控中，若是 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操做速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

• • 太高的磁盘利用率(high disk utilization)
  • 太长的磁盘等待队列(large disk queue length)
  • 等待磁盘I/O的时间所占的百分率过高(large percentage of time waiting for disk I/O)
  • 过高的物理I/O速率:large physical I/O rate(not sufficient in itself)
  • 太低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
  • 太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1. SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。若是持续低于80%，应考虑增长内存。
2. 若是Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以肯定是否确实须要全表扫描，以及SQL查询是否能够被优化。
3. Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性很是有害，而且会致使恶劣的用户体验。该计数器的值必须为0。
4. Lock Requests/sec(锁请求/秒)，经过优化查询来减小读取次数，能够减小该计数器的值。

Oracle数据库：

• 若是自由内存接近于0并且库快存或数据字典快存的命中率小于0.90，那么须要增长SHARED_POOL_SIZE的大小。

　　快存（共享SQL区）和数据字典快存的命中率：

　　　　select(sum(pins-reloads))/sum(pins) from v$librarycache;
　　　　select(sum(gets-getmisses))/sum(gets) from v$rowcache;

　　自由内存:

　　　　select * from v$sgastat where name=’free memory’;

• 若是数据的缓存命中率小于0.90，那么须要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

　　缓冲区高速缓存命中率：
　　　　select name,value from v$sysstat where name in (‘db block gets’,‘consistent gets’,'physical reads’) ;

　　　　Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

• 3 若是日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。 日志缓冲区的申请状况：

　　　　select name,value from v$sysstat where name = ‘redo log space requests’ ;

• 4 若是内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以免磁盘排序。

　　　　内存排序命中率：