1、判断CPU瓶颈：

 a、%processor time 平均值大于95

 b、processor queue length 大于2（大于处理器个数+1）。可以确定CPU瓶颈

 c、CPU空闲时间为零（zero percent idle CPU）

 d、过高的用户占用CPU时间（%User Time）

  e、过高的系统占用CPU时间（%Priviliaged Time:长期大于90%或者95%）

备注：

 %User time(processor_total)表示耗费CPU的数据库操作、如排序、执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

 如果发现processor queue length 显示的对猎场度超过2，而处理器的利用率却一直很低，或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。

2、判断内存瓶颈与内存泄漏

  a、如果发生了内存泄漏，process\privatebytes计数器和process\workingset计数器的值往往会升高，同时avaiable bytes的值会降低

  b、如果Available Mbytes（剩余物理内存数）的值很小（4MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

3、定位磁盘瓶颈

  a、% Disk Time 和 Avg.Disk Queue Length 的值（应不大于组成屋里磁盘的主轴数的1.5到2倍）很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶颈。

 b、Physical Disk\ Disk Reads/sec and Disk Writes/sec大于20ms，则有可能磁盘瓶颈

 c、Avg. Disk sec/Transfer 盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了。

 e、Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3,此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换硬盘。

备注：如果使用RAID设备，%Disk Time计数器会指示大于100%的值

4、定位网络瓶颈

  Byte Total/sec表示网络中接受和发送字节的速度，可以用该计数器来判断网络是否存在瓶颈（参考值该计数器和网络宽带相除,<50%）

5、SQL Server相关

 a、SQLServer：CancheManage->Canche Hit Ratio显示在高速缓存中找到数据的命中率。如果数值持续小于85%，则表示内存有问题

 b、SQLServer:Locks->Lock Waits/sec显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于0，则表示事务有问题。

                                                                                    性能瓶颈分析方法

同一场景

1、小用户量的情况下测试

2、大用户量的情况下测试

分析的方法：整个系统架构分析，系统响应时间消耗，利用图标分析

查看事务响应时间，通过事务摘要图分析事务响应时间，哪个消耗最大（通过小用户和大用户量的响应时间分析，查看哪个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，

查看cpu

使用下列计数器标识cpu瓶颈

Processor\ Interrupts/sec

Processor\%Processor Time

Processor(process)\%Processor Time

System\Processor Queue Length

通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！

下一步去判断进程，哪个进程消耗cpu最高

下边就有很多中情况需要你I帧及去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）

性能产生瓶颈有很多地方，所以需要进一步判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断

分析原则：

      查找瓶颈时按以下顺序，由易到难。

      服务器硬件瓶颈 —> 网络瓶颈（对局域网、可以不考虑）—>服务器操作系统瓶颈（参数配置）—>中间件瓶颈（参数配置，数据库，web服务器等）—>应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

  注：以上过程并不是每个分析汇总都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

  分析排除法 很有效

分析的信息来源：

 a、根据场景运行过程中的错误提示信息

b、根据测试结果收集到的监控指标数据

一、错误提示分析

分析实例：

a、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

分析：

 a1、应用服务死掉（小用户时：程序上的问题。程序上处理数据库的问题）

 b1、应用服务器没有死（应用服务参数设置问题）

    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25%

c1、数据库的连接

 （1、在应用服务的性能参数可能太小了

    2、数据库启动的最大连接数（跟硬件的内存有关））

b、Error： Page download timeout（120 seconds） has expired

分析：可能是以下原因造成的。

1)应用服务参数设置太大导致服务器的瓶颈

2）页面中图片太多

3）在程序处理表的时候检查字段太多

二、监控指标数据分析

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%

       合理使用的范围在60%至70%。

      2、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、SQL Server资源监控中指标缓存点击率（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';

2、如果数据的缓存命中率小于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以避免磁盘排序。

         内存排序命中率:

          select rund((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2) from  v$syssstat a,V$sysstat b where s.name = 'sorts(disk)'

             and  b.name='sorts(memory)'

   注：上述SQL Server 和 Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。