性能测试瓶颈分析和报告

系统瓶颈分析

一、系统瓶颈分析示例
例1：
　　交易的响应时间如果很长，远远超过系统性能需求，表示消耗CPU的数据库操作，例如排序、执行aggregate functions（例如sam、min、max、count）等较多，可以考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格等方法来降低该值。
例2：
　　分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问web服务器、应用服务器和数据库服务器，这样就可以在web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。
例3：
　　Unix资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续走高，则内存可能是瓶颈。也可能是内存访问命中率低。“swap in rate”和“swap out rate”也有类似的解释。
例4：
　　Unix资源监控（NT操作系统同理）中指标CPU占用率（cpu utilization），如果该值持续超过95%，表明cpu是瓶颈，可以考虑增加一个处理器或换一个更快的处理器。合理使用范围在60%至70%。
例5：
　　Unix资源监控（NT操作系统同理）中指标磁盘交换率（Disk rate），若果该值参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等，另外设置Tempdb in RAM，减低“max async IO”，“max lazy writer IO”等措施都会降低该值。
例6：
　　Tuxedo资源监控中指标列队中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个raid disk实际有多个磁盘。
例7：
　　Sqlserver资源监控中指标缓存点击率（cache hit ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从sql server启动后，就一直累加记数，所以运行一段时间后，该值不能反映系统当前值。
二、系统优化调整设置
1、CPU问题：
　　考虑使用更高级的CPU代替当前的CPU。
　　对于多CPU,考虑CPU之间的负载分配。
　　考虑在其他体系上设计系统，例如增加前置机，设置并行服务器等。
2、内存和高速缓存：
　　内存的优化包括操作系统、数据库、应用程序的内存优化。
　　过多的分页与交换可能降低系统的性能。
　　内存分配也是影响系统性能的主要原因。
　　保证保留列表具有较大的邻接内存块。
　　调整数据块缓冲区大小（用数据块的个数表示）是一个重要内容。
　　将最频繁使用的数据保存在存储区中。
3、磁盘（I/O）资源问题
　　磁盘读写进度对数据库系统是至关重要的，数据库对象在物理设备上的合理分布能改善性能。
　　磁盘镜像会减慢磁盘写的速度。
　　通过把日志和数据库对象分布在独立的设备上可以提高系统的性能。
　　把不同的数据库放在不同的硬盘上，可以提高读写速度。经常把数据库、回滚段、日志放在不同的设备上。
　　把表放在一块硬盘上，把飞簇的索引放在另一块硬盘上，保证物理读写更快。
4、调整配置参数
　　包括操作系统和数据库的参数配置。
　　并行操作资源限制的参数（并发用户的数目、会话数）。
　　影响资源开销的参数。
　　与I/O有关的参数。
5、优化应用系统网络设置
　　可以通过数组接口来减少网络呼叫。不是一次提取一行，而是在单个往来往返中提取10行，这样做效率较高。
　　调整会话数据单元的缓冲区大小。
　　共享服务器进程比专用服务进程提供较好的性能。
三、数据库服务器性能问题及原因分析
1、单一类型事务响应时间过长
　　数据库服务器负载、糟糕的数据设计、事务粒度过大、批任务对普通用户性能的影响。
2、并发处理能力差
3、锁冲突严重
　　资源锁定造成的数据库事务超时、数据库死锁。
四、数据库相关
1、数据库性能问题的一般解决办法
　　监视性能相关数据。
　　定位资源占用较大的事务并做出必要的优化或调整。
　　定位锁冲突，修改锁冲突发生严重的应用逻辑。
　　对规模较大的数据或者无法通过一般优化解决的锁冲突进行分布。
2、oracle与提高性能有关的特性
　　索引、并行执行、簇与散列簇、分区、多线程服务器、同时读取多块数据。
3、oracle配置的关键参数
　　MAX_DSPATCHERS：这个参数指定了系统允许同时进行的调度进程的最大数量。
　　MAX_SHARED_SERVERS：这个参数指定了系统允许同时进行的共享服务器进程的最大数量。如果系统中出现的人为死锁过于频繁，那么管理员应该增大这个参数的值。
　　PARALLEL_ADAPTIVE_MULTI_USER：当这个参数的值为TRUE时，系统将启动一个能提高使用并行执行的多用户系统性能的自适应算法。这个算法将根据查询开始时的系统负载自动降低查询请求的并行度。
　　PARLLEL_MIN_SERVERS：这个参数指定了实例并行执行进程的最小数量。其值就是实例启动时Oracle创建的并行执行进行数。
　　PARLLEL_THREADS_PER_CPU：这个参数指定了实例默认的并行度和并行自适应以及负载平很算法。它指明了并行执行过程中一个CPU能处理的进程或线程数。
　　PARTITION_VIEW_ENABLED：这个参数指定了优化器是否使用分区视图。oracle推荐用户使用分区表（这个在oracle8之后引入的）而不是分区视图。分区视图只是为了提供oracle的后向兼容性。
　　REVOVERY_PARALLELISM：这个参数指定了恢复数据库系统时使用的进程数。
4、oracle的并行执行特性
RDBMS的绝大多数操作都可以分为以下3类：
被CPU限制的操作：这类操作的速度和单CPU运行的速度一样。通过并行化操作，多个CPU可并行处理系统负载，因为可以更快完成该操作。
被I/O限制的操作：这类操作花了绝大部分时间等待系统完成I/O操作。当系统中同时出现多个I/O请求时，绝大多数RAID控制器将很好工作。另外，当一个线程需要等待完成I/O操作时，可充分利用CPU来处理另一个线程的CPU部分。
被竞争限制的操作：并行处理不能改善由资源竞争所限制的操作。
5、应当首先根据如下一些因素考虑并行度：
计算机的CPU能力：CPU的数量和能力将影响系统能运行的查询进程数量。
系统处理大量进程的能力：一些操作系统能处理很多并发线程，而另一些操作系统则没有这方面的能力。
系统负载：如果系统现在的运行已经达到了极限，那么对并行度的调整不会有太大的效果。如果系统运行已达其能力极限的90%，那么大多的查询进程将使系统不堪重负。
系统处理的查询数量：如果系统的大部分操作是更新操作，但仍有少量的重要查询存在，那么开发人员可能希望系统运行多个查询进程。
系统的I/O能力：如果磁盘上的数据是分片或是使用磁盘阵列存储的，那么系统能够处理多个并行查询。
操作类型：系统是否需要处理很多的全表扫描或排序：并行查询服务器非常有助于这类操作。
6、关于并行度的一些建议：
　　诸如排序之类的需要大量CPU资源的操作应当使用较低的并行度。其原因是这类受限于CPU的操作已经充分利用的CPU，而不需要等待系统的I/O操作。
　　诸如全表扫描之类的需要大量磁盘I/O的操作应当采用较高的并行度。需要等待磁盘I/O的操作越多，系统就越能受益于并行操作。
　　如果系统中有大量的并发进程，那么应当采用较低的并行度。因为太多的进程将使系统不堪重负。
7、Oracle同时读取多块数据
　　当系统执行表扫描时，oracle具备同时读取多个数据块的能力，这种能力提高了系统的I/O速度。通过同时读取多块数据，oracle能够从磁盘上读取更大的数据块，从而避免了对磁盘上数据进行搜索的操作。通过降低磁盘搜索和读取更大的数据块，可以降低系统的I/O开销和CPU开销。
8、oracle 的分区
分区方案：
　　Range Partitioning：这种方案根据数据的范围，比如月、年等对表中的数据进行分区。
　　List Partitioning：这种方案和Range Partitioning分区方案很类似，但这种方案是按照数据的值而不是数据的范围来进行分区划分的。
　　Hash Partitioning：这种分区方案使用散列函数来实现对数据的自动分区。
　　Sub-Partitioning：这种方法就是开发人员熟悉的复合分区方法。这种方法允许开发人员同时使用多种分区方案。
分区有以下几方面的好处：
　　对能被分区的大尺寸表进行扫描时，分区可降低I/O操作和CPU的使用率。
　　可在分区的层次上而不是表的层次上加载数据。
　　能以删除分区的方式删除数据，而不必使用select语句来删除大量数据。
　　对用户和应用程序而言，分区是完全透明的。
　　可在分区层次上而不是在表层次上维护数据。
9、oracle的多线程服务器
　　用户可以通过专用服务器进程连接到oracle实例，也可以通过多线程服务器进程连接到oracle实例。因为每一个专用的服务器进程都将占用大量的内存资源和系统资源，所以有必要对多用户连接采用多线程服务器进程。
　　多线程服务器进程允许多个用户使用一定数量的共享服务器进程。共享服务器进程使用共享缓冲池对用户请求进行排队并返回数据，从而大大减少CPU和内存的使用。
10、oracle故障诊断
　　数据库故障诊断通过获得系统sql语句执行性能数据，例如每一条sql语句在oracle数据库中执行的平均时间，来识别问题发生位置。
　　为了分析故障位置，将故障诊断数据（oracle Diagnostics）与交易执行响应时间（Transaction Response Time）数据关联起来。例如：某交易“enter”的平均响应时间高，使用故障诊断（Oracle diagnostics），就可以查找到是什么原因导致了这个问题。

报告的编写：

1.测试目的

2.测试范围——涉及业务

3.测试环境——服务器环境，客户端环境，网络环境

4.业务场景建模
业务场景（该性能测试业务流程）场景设置策略：（例）慢增长方式，逐步加压，达到XX个Vuser后保持运行，最终整个场景耗时12分钟。

5.测试结果分析
把分析的关键数据图表以及描述进行整合，最好写出初步推理猜想。

6.测试结论与解决方案
1）服务器硬件方面：随着并发用户的增加，系统CPU使用率的增加，并且出现明显的排队现象，说明硬件存在瓶颈。
解决方案：可增加或替换更好的CPU和磁盘。