吞吐量达到瓶颈后下降_应用系统瓶颈查找

网站响应慢了，用户开始埋怨，老大安排你去优化，可是优化如何开始呢。优化开始前一定要理清思路，问自己，网站的瓶颈在哪里。

系统的瓶颈在何方呢?如果你的系统有完善的监控分析系统的话，可以从统计数据和图形上看到大致的系统瓶颈所在，但是如果你的系统没有这些数据，你又如何来确定系统的瓶颈呢。按照一般的思路，我们对系统进行逻辑功能的划分，如静态服务器，动态服务器，数据库服务器，业务逻辑服务器。分别针对对这些服务器的带宽、内存使用、cpu使用率、磁盘使用情况进行分析，如对于动态服务器而言，其cpu的使用率一般情况下是其瓶颈；而对于静态文件服务器，由于其逻辑简单，但需要传输大量的文件，其出口的带宽很有可能是其瓶颈；对于数据库服务器，cpu和磁盘都有可能是瓶颈。我们可以通过如下几个方面来进行查找和排除：

1 网络带宽

带宽可能是最直接的一个瓶颈，可以很容易的估计到。假如运营商给你提供了10M的带宽，注意带宽的单位是bit，如果你的一个页面的大小是10K字节，那么一秒钟的最多的并发量这样计算：10*1024/8/10=128如果每秒并发超过这个数字，你的带宽就无法接受了。或者通过netstat命令来观察一下你的网络收发包的情况，使用netstat

-s来观察一些统计的数据，如果发现等待包队列里总是有大量的包待处理，一方面说明可能你的程序有问题，另一方面说明可能你的并发量太大，系统已经处理不过来了，可能已经开始丢包了。按照这个两个思路去检查吧。可以通过内外网的速度进行对比，若内网速度很好，而外网应用起来很慢，则肯定是网络带宽不够。

2 CPU

如果带宽不是问题，又有这么大的并发量，下一个很容易是问题的就是你的cpu了。如果你的网站有大量的动态请求，如php操作数据库后再返回，cgi代码逻辑里有大量的排序等耗费cpu的操作，或者是你的cgi程序写的不好，会死循环，这时你的cpu就将成为瓶颈。在linux上试试top命令，看看你的机子的负载，通过最右上角的1分钟、5、15分钟采样的平均负载可以看到你的机子在一段时间内的一个负载情况，如果过去15分钟你的机子的负载大于你的cpu的数目*5，说明你的机子很繁忙了，很多进程都需要等待处理了。或者vmstat

-n 1命令，看看你的cpu idle的时间有多少，等待处理的进程数量有多少，磁盘块的读写有多少。如果cpu

idle的时间很少，或者等待处理的进程数量很多，说明你的系统比较繁忙。若是cpu的问题，需要进一步分析，看看到底是cpu的主频不够(相当于高速公路的最高限速)还是cpu的内核数量不够(相当于高速公路的车道)。

3 磁盘操作

如果你的带宽很大，cpu比较的空闲，接下来的瓶颈很可能是磁盘的io操作了。从内存读取数据是相当快的，但是从硬盘读取数据是内存读取数据的50到100倍的时间，使用iostat

-dx查看一下你的硬盘操作的情况，如果有大量的block阻塞着等待写入到硬盘，你需要检查一下你的代码，看看是否有大量的日志操作，或者写文件的操作阻塞住了。

4 业务逻辑服务器响应慢

如果上述都ok，而且你的cgi又连接到其它的业务逻辑服务器请求数据的情况，你需要检查你与业务逻辑服务器之间的连接是否正常，带宽是否够用，你的业务逻辑服务器的性能如何。

5 内存不够用

对于一些大容量缓存的业务服务器，如果缓存过多的内容，淘汰策略不好的话，会导致使用掉过多的内存，从而引起操作系统进行大量的swap交换，进而影响到系统的性能，成为瓶颈。通过ipcs

-a观看系统的使用的共享内存的情况，如果共享内存使用太多的话，考虑较少一点共享内存的大小。使用free来来观察系统的内存使用情况，如果发现空闲的内存空间少，使用top命令，然后ctl+M看看那些进程占用了大量的内存，适当关掉一些进程，部署在其它的服务器上。

实际面临的问题

在云环境中，基础架构和上层服务的管理被分开了，定位性能问题以及其原因需要花费大量的时间和成本，如何保证对用户承若的服务级别成了重大的课题。

1、云环境化的推进平台统合使得其与系统性能之间的依赖关系变复杂了。

2、底层和上层的管理者分开造成区分性能问题的困难由于复杂系统配置的原因，人为的误操作常发生。

3、依靠管理者的经验和分析来发现和查明原因要花很长时间。

解决之道

系统的性能瓶颈原因的分析，不仅需要IT的基础架构的性能信息，中间件(Web/AP服务器、DB等)、Web应用内部细致的性能信息也必须可视化。此外，还需要降低收集的大量的性能信息的分析成本，实时把握之间的关系，缩短减少查找原因的时间。

1、性能瓶颈分析解决方案

从Web应用的响应缓慢的发现开始，到发现瓶颈在IT基础架构中的位置。另外能自动可视化、分析、查找黑盒的J2EE应用内部的性能信息。

OPERATIONS>

2、测试Web响应、发现性能问题

使用MasterScope Application

Navigator，从终端用户的感受视点出发，在一段时间内对IT服务进行模拟访问，监视End to End的响应连通情况。

3、进行多个服务器的性能相关分析，发现成为原因的服务器

MasterScope

MISSION CRITICAL OPERATIONS除了收集服务器、OS的性能信息外，还能对MasterScope

Application Navigator收集的数据库、应用等中间中间件的性能信息进行统一管理。

对于这些收集的性能信息，不需要进行阈值设定等繁琐的操作，MasterScope Invariant

Analyzer使用独有的技术自动的进行相关，由此，能从视觉上把握和平时不一样的行为，查找成为瓶颈原因的服务器就能比较容易了。

4、从原因服务器的详细性能中定位原因要素

原因服务器中有应用服务器的时候，用CA

Introscope可视化通常黑盒化的J2EE应用的内部性能信息，从数万众性能信息中，MasterScope Invariant

Analyzer能进行Web应用的事务基本的原因分析。

如果原因是在WebOTX

Application

Server基础上构建的J2EE的应用，导入其“性能改善方案”，浏览对应的性能改善方法，发生的性能问题能迅速改善。

5、综合工具进行一致的性能分析

MasterScope

MISSION CRITICAL

OPERATIONS能进行从基础架构到Web应用内部的性能问题的发现和原因查找，能进行一致的性能分析的统一运维。

解决方案产品群

系统性能分析：MasterScope Invariant Analyzer

应用管理：MasterScope Application Navigator

综合管理：MasterScope MISSION CRITICAL OPERATIONS

基本原则

1.具体问题具体分析(应用系统业务不同，测试目的和性能关注点也有所不同)2.查找瓶颈时可按以下顺序，由易到难逐步进行分析确认。服务器硬件瓶颈-〉网络瓶颈(对局域网，可以不考虑)-〉服务器瓶颈(参数配置)-〉中间件瓶颈(参数配置，，服务器等)-〉应用瓶颈(语句、数据库设计、业务逻辑、算法等)注意：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下，系统的硬件瓶颈在哪儿就够了。

遇到错误时，要根据场景运行过程中的错误提示信息和测试结果收集到的监控指标数据分析的信息原因，如以下常见错误情况分析：一．根据错误提示分析分析实例：实例1 •Error: Failed to connect to“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、数据库的连接异常a、在应用服务的性能参数可能太小了

b、数据库启动的最大连接数(跟硬件的内存有关))

实例2 Error: Page download timeout (120 seconds) has expired分析：可能是以下原因造成•A、应用服务参数设置太大导致服务器的瓶颈•B、页面中图片太多•C、在程序处理表的时候检查字段太大多二．监控指标数据分析1．最大并发用户数：

应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。

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

1.UNIX资源监控中指标内存页交换速率(Paging rate)，如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2.资源监控中，如果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)

磁盘阵列吞吐量与IOPS两大瓶颈分析

本文是由NSIDC总结的，分析了磁盘阵列的瓶颈，主要体现在2个方面：吞吐量与IOPS。

1、吞吐量

吞吐量主要取决于阵列的构架，光纤通道的大小(现在阵列一般都是光纤阵列，至于SCSI这样的SSA阵列，我们不讨论)以及硬盘的个数。阵列的构架与每个阵列不同而不同，他们也都存在内部带宽(类似于pc的系统总线)，不过一般情况下，内部带宽都设计的很充足，不是瓶颈的所在。

光纤通道的影响还是比较大的，如数据仓库环境中，对数据的流量要求很大，而一块2Gb的光纤卡，所能支撑的最大流量应当是2Gb/8(小B)=250MB/s(大B)的实际流量，当4块光纤卡才能达到1GB/s的实际流量，所以数据仓库环境可以考虑换4Gb的光纤卡。

最后说一下硬盘的限制，这里是最重要的，当前面的瓶颈不再存在的时候，就要看硬盘的个数了，我下面列一下不同的硬盘所能支撑的流量大小：

10 K rpm 15 K rpm ATA

——— ——— ———

10M/s 13M/s 8M/s

那么，假定一个阵列有120块15K rpm的光纤硬盘，那么硬盘上最大的

可以支撑的流量为120*13=1560MB/s，如果是2Gb的光纤卡，可能需要6块才能够，而4Gb的光纤卡，3-4块就够了。

2、IOPS

决定IOPS的主要取决与阵列的算法，cache命中率，以及磁盘个数。阵列的算法因为不同的阵列不同而不同，如我们最近遇到在hds

usp上面，可能因为ldev(lun)存在队列或者资源限制，而单个ldev的iops就上不去，所以，在使用这个存储之前，有必要了解这个存储的一些算法规则与限制。

cache的命中率取决于数据的分布，cache

size的大小，数据访问的规则，以及cache的算法，如果完整的讨论下来，这里将变得很复杂，可以有一天好讨论了。我这里只强调一个cache的命中率，如果一个阵列，读cache的命中率越高越好，一般表示它可以支持更多的IOPS，为什么这么说呢?这个就与我们下面要讨论的硬盘IOPS有关系了。

硬盘的限制，每个物理硬盘能处理的IOPS是有限制的，如

10 K rpm 15 K rpm ATA

——— ——— ———

100 150 50

同样，如果一个阵列有120块15K

rpm的光纤硬盘，那么，它能撑的最大IOPS为120*150=18000，这个为硬件限制的理论值，如果超过这个值，硬盘的响应可能会变的非常缓慢而不能正常提供业务。

在raid5与raid10上，读iops没有差别，但是，相同的业务写iops，最终落在磁盘上的iops是有差别的，而我们评估的却正是磁盘的IOPS，如果达到了磁盘的限制，性能肯定是上不去了。

那我们假定一个case，业务的iops是10000，读cache命中率是30%，读iops为60%，写iops为40%，磁盘个数为120，那么分别计算在raid5与raid10的情况下，每个磁盘的iops为多少。

raid5:

单块盘的iops = (10000*(1-0.3)*0.6 + 4 *

(10000*0.4))/120

= (4200 + 16000)/120

= 168

这里的10000*(1-0.3)*0.6表示是读的iops，比例是0.6，除掉cache命中，实际只有4200个iops

而4 * (10000*0.4)

表示写的iops，因为每一个写，在raid5中，实际发生了4个io，所以写的iops为16000个

为了考虑raid5在写操作的时候，那2个读操作也可能发生命中，所以更精确的计算为：

单块盘的iops = (10000*(1-0.3)*0.6 + 2 *

(10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120

= (4200 + 5600 + 8000)/120

= 148

计算出来单个盘的iops为148个，基本达到磁盘极限

raid10

单块盘的iops = (10000*(1-0.3)*0.6 + 2 *

(10000*0.4))/120

= (4200 + 8000)/120

= 102

可以看到，因为raid10对于一个写操作，只发生2次io，所以，同样的压力，同样的磁盘，每个盘的iops只有102个，还远远低于磁盘的极限iops。

在一个实际的case中，一个恢复压力很大的standby(这里主要是写，而且是小io的写)，采用了raid5的方案，发现性能很差，通过分析，每个磁盘的iops在高峰时期，快达到200了，导致响应速度巨慢无比。后来改造成raid10，就避免了这个性能问题，每个磁盘的iops降到100左右。

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(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。数据库：1.如果自由内存接近于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 round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

应该系统瓶颈分析经验：对于那些拥有不同目标客户同时需要进行参数配置的产品，很多时候由于配置不正确导致系统性能不高。

数据库瓶颈分析经验：数据库经常由于配置或者设计不合理产生瓶颈，通过在项目中积累经验，可以在以后的测试分析中对数据库问题快速定位。例如Oracle拥有100多个可以配置的参数，经常由于配置问题导致运行缓慢，通过积累解决这方面问题的经验，测试人员完全可以象DBA一样快速解决问题。

Web服务器分析：Web服务器和数据库服务器一样，经常由于配置不合理导致系统产生瓶颈，因此也应该总结测试中解决问题的经验，以后实习项目遇到类似的问题就可以快速解决，可省去厂商的高额技术支持成本。

操作系统及硬件：操作系统以及硬件资源也是系统产生瓶颈的根源之一，通过分析总结应用系统在不同配置环境下的表现，可以为以后的测试提供有利的参考。