性能工程系列之一性能测试篇

性能工程系列之二性能调优介绍PQA测试部2010年5月1议题Oracle调优Aix系统调优WebLogic调优2调优被分成不同的阶段:应用设计和开发数据库配置布署应用故障解决和调优3调优基本原则如果某个部分不是瓶颈，就不要尝试去优化优化是为系统提供足够的资源并且充分的使用资源，而不是无节制的扩充资源优化有时候也意味着合理的分配或者划分任务优化可能会过头，注意协调整个系统的性能4OracleTuning5优化的基本方法设立合理的性能优化目标测量并记录当前性能selectsysteminformation确定当前oracle的性能瓶颈（等待什么）把等待事件记录确定当前的os瓶颈优化所需的部分（应用程序、数据库、i/o、争用、os、存储、网络等）跟踪并实施更改过程测量并记录当前性能重复3-7，直到满足优化目标6Oracle9i内存建议视图及参数V$DB_CACHE_ADVICEV$SHARED_POOL_ADVICEV$PGA_TARGET_ADVICEdb_block_sizedb_cache_sizedb_Processessga_max_size7等待事件两类等待事件：空闲等待：oracle正在等待某种动作的发生clientmessage(客户机消息)；NULLevent（NULL事件）；pipeget（管道取操作）；SQL*NETmessagefromclient（来自客户端的消息）；rdbmsipcmessage(数据库icp消息)等非空闲等待事件：数据库发生了竞争bufferbusywaits(数据高速缓存忙等待)；dbread(数据文件离散读取)；dbread(数据文件顺序读)；enqueue(队列)、freebufferwaits(空闲缓冲区等待)；latchfree(拴空闲)；logwrite(日志文件并行写入)；log(日志文件同步)等8常见非空闲等待事件bufferbusywaits(数据高速缓存忙等待，多个进程在对一个块做操作)dbwrite(数据文件并行写)dbread(数据文件离散读取)dbread(数据文件顺序读)dbwrite(数据文件单次写)directpathread(直接路径读取)directpathwrite(直接路径写出)enqueue(队列)freebufferinspected(空闲数据缓冲区探测)freebufferwaits(空闲缓冲区等待)latchfree(锁存器空闲)librarycacheloadlock(库高速缓存装载锁)9常见非空闲等待事件librarycachelock(库高速缓存锁)librarycachepin(库高速缓存执行锁)logbufferspace(日志缓冲区空间分配)logwrite(日志文件并行写入)logwrite(日志文件单次写)，提交频繁会出现log(archivingneeded)归档没完成，造成logwrite不能覆盖，log(checkpointincomplete)log(日志文件同步)timerinsksawat(归档过慢)Transaction(事务阻塞)undosegmentextension(回滚段动态扩展，回滚段不停的动态扩展，事物大，事物长时间不结束)10检查I/O统计的诊断SQL>selectd.tablespace_nameTABLESPACE,d.,f.phyrds,f.phyblkrd,2>f.readtim,f.phywrts,f.phyblkwrt,f.writetim3>fromv$f,dba_data_filesd4>wheref.file#=d.orderbytablespace_name,;TABLESPACEPHYRDSPHYBLKRDREADTIMPHYWRTSPHYBLKWRTWRITETIM

USERS/u03/users01.dbf65012416752384205645648860SAMPLE/u02/sample01.dbf880880SYSTEM/u01/system01.dbf806153819851161161721TEMP/u04/temp01.dbf1686664836756750……..1)Users有65012次读、564次写，而sample为8次读、8次写，说明数据分布不均衡把users中的表movie到sample上2)索引访问才8块，而数据访问为416752块,说明索引和表放在同一个表空间上而没有放在索引表空间上3)通过users可以看出,65012次读确读到了416752个块,说明单次读了多块,大概一个io读了6块,说明走的是全表扫描,没有有效利用索引,索引一个io尽读一个块,因此索引有问题,可能没有使用索引、可能就要求全表扫描,system为806块,可能用户表放在这里了,或者发生解析需要用到数据字典信息。11索引--数据库加速利器逻辑上单列/组合索引唯一/非唯一索引物理上

分区或非分区B树正常或反向键位图12创建索引:提示平衡查询与DML操作的需求.将索引放在单独的表空间.对于大的索引考虑使用NOLOGGING.索引的INITRANS应该比相应表的INITRANS设置的高一些.插入操作导致在适当的块中插入索引项删除行只导致逻辑删除索引项，删除的行所占用的空间难以用于新项，直到删除块中的所有项,所以对于更新和删除比较多的索引需要定期重建,保持索引的性能.13索引为何失效？对索引字段进行计算索引字段与数据类型不符合不等于符号对索引字段使用了函数(to_date,to_char)查询数据选取范围过大复合索引的前导列未被使用字符可以转换成数字优先级别高的使用索引14重建索引SQL>ANALYZEINDEXacct_no_idxVALIDATESTRUCTURE;Indexanalyzed.表的名称为indx_stats;SQL>SELECT(DEL_LF_ROWS_LEN/LF_ROWS_LEN)*1002ASwastage3FROMindex_stats;pct_used越低建议重建WASTAGE

24如果Wastage>20%就应该考虑重建！SQL>ALTERINDEXacct_no_idxREBUILD;Indexaltered.15索引可能降低查询性能若查询数据比例占表数据百分比过大则降低性能影响百分比大小的因素IO能力buffercache大小数据有序度（dba_indexes.CLUSTERING_FACTOR）表数据行大小与block大小16优化模式在Oracle9i,两种优化模式可以被选择:基于规则的Rule-based:使用一个分级系统语法(Syntax)驱动和字典(dictionary)驱动的Oracle从早期版本提供RBO优化器，至Oracle10g该优化器不再被支持基于代价的Cost-based:选择最低代价的路径统计(Statistics)驱动,静态的统计信息从Oracle7(1992)>Oracle10g主要支持的优化器17设置优化模式在实例级:optimizer_mode={choose|rule|first_rows|first_rows_n|all_rows}在会话级:altersessionsetoptimizer_mode={choose|rule|first_rows|first_rows_n|all_rows}在语句级:使用提示(hints)18SoftparseandHardparseSoftparse软解析，通过hash计算查找sql在共享池中存在于是重用执行计划的过程Hardparse硬解析，通过hash计算查找发现sql在共享池中不存在，于是重新产生执行计划的过程

软解析和硬解析对资源的消耗差异很大19SQL优化基本原则减少重分析合理使用索引使用合理的表连接方式减少不必要的排序降低逻辑读20数据库共享池为什么要使用共享池

SQL解析代价比较高 有限周期内系统一般运行大量重复代码 系统的sql数量总是有限的 合理的使用共享池能够降低重分析的次数如何减少重分析的次数 配置足够大的共享池 采取统一的语句书写规则 使用绑定变量 在不能使用绑定变量的基础上使语句实现代码共享21不使用绑定的影响使用更多的共享池来缓存sql和执行计划使用更多的cpu资源将产生更多的数据库内部锁导致共享池管理代价的增加22数据库对绑定的补救措施Cursor_sharing=force/exact/similar我们为什么还要强调在程序中绑定cursor_sharing存在bugcursor_sharing影响sql执行计划cursor_sharing消耗额外内存和cpu在应用中绑定的代价低，维护的代价很高由数据库设置Cursor_sharing风险很高23连接方式合并连接（sortmergejoin）:是集合的合并操作，一般是在没有有效的索引时使用循环嵌套连接（nestedloopjoin）:是一种循环的行操作，对于事务型处理是首选。在OLTP系统中常见，使用有效的索引来执行操作。散列连接（hashjoin）:使用连接表的全表扫描完成。Oracle执行每个表的全表扫描，并根据内存情况，将每个表分成所需的多散列分区，然后通过另一个表的相应分区试探这个散列表。散列连接适合大表的连接。注意设置合适的参数：hash_area_size和hash_mutilblock_io_count24RBO下Sql语句的优化规则在RBO模式下，Sql语句的执行遵循着规则级别的优先级：SinglerowbyROWIDSinglerowbyclusterjoinSinglerowbyhashclusterkeywithuniquekeySinglerowbyuniqueindexClusterjoinHashclusterkeyIndexedclusterkeyCompositekeySingle-columnnon-uniqueindexBoundedrangesearchonindexedcolumnsUnboundedrangesearchonindexedcolumnsSort-mergejoinMAXorMINofindexedcolumnORDERBYonindexedcolumnsFulltable-scan25写SQL语句的一些提示从I/O的观点来看，使用索引没有意义时建议使用全表扫描如果查询中包含了子查询，那么注意首先优化子查询注意关联子查询，尽量减少关联子查询的使用，因为它的代价很高，并且非常消耗CPU在Sql语句中使用notexists代替notin用表连接替换EXISTS使用带有前导字段的like来替换substr函数考虑使用unionall代替多个or连接操作如果经常执行主细表的联合查询，建立外键索引考虑使用非唯一索引支持唯一性约束条件26写SQL语句的一些提示主动的确定使用循环嵌套、合并连接、散列连接，尽可能测试使用一种代价较小的连接方式。如果需要在pl/sql程序中使用动态sql，建议使用executeimmediate对于非常大的表，考虑使用表和索引的分区如果需要在创建索引的时候减少所需时间，可以在会话集设置比较大的sort_area_size考虑更多的使用decode函数，而不是在pl/sql中作判断一定要周期性的收集信息，及时发现系统中的潜在问题27写SQL语句的一些提示选择最有效率的驱动表很多情况下ORACLE并不能为我们的SQL语句选择最有效的驱动表,在我们自己确定了合适的驱动表之后,可以使用HINT:ORDERED,LEADING来指定合适的驱动表WHERE子句中的连接条件书写顺序那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾减少对表的访问次数（减少逻辑读）避免索引列的类型隐式转换造成的索引无效28AIXTuning29AIX性能分析与故障诊断掌握基本的性能调试工具掌握基本的故障诊断工具30一般性能分析过程CPU瓶颈？内存瓶颈？I/O瓶颈？网络瓶颈？vmstatpslspssvmonvmstatsarnicepsiostatlslvMoretestnetstatnfsstatnfsonoifconfignetpmonYYYYNNNN31性能分析工具 iostat vmstat sar topas svmon32iostatCPU的使用状态－%user，表示平均用户占用时间－%sys，表示系统花费CPU时间－%idle，表示CPU空闲时间－%iowait，表示CPU等待I/O所花费时间33iostat分析：如果%idle数值都很高而且%iowait数值也很高，大于25，这个说明系统存在I/O或则硬盘瓶颈内存不够而引起频繁的swap空间的数据交换，导致数据存取存在交换空间的I/O瓶颈硬盘上面数据不合理的分布数据的fragment不合理高数值的%iowait有可能下面几个原因：34iostat硬盘使用状态－%tm_act表示某个硬盘处于active状态的百分比－tps表示每秒某个硬盘有多少个数据传输次数－Kb_readKb_wrtn分别显示从开机到运行iostat这个命令这段时间内对硬盘的read和write的总数据量，单位kb

35vmstat CPU空闲时间百分比=id%+wa%

算CPU平均一分钟空闲多少时间

(99＋92＋95＋86+7＋96)÷100÷5×60＝56.16(秒)36vmstatkthr参数

－r 等待CPU运行的队列个数 若r数值偏大，表明CPU太忙

－b 等待I/O操作的阻塞队列个数 若b数值偏大，表明系统I/O出现瓶颈37vmstatCPU瓶颈如果sy和us参数的数值加起来接近100，表示系统CPU使用率太高，同时也会看到r的数值也大于1内存瓶颈

内存不足，换页将变得频繁，这时pi(in)和po(out)参数将不是0，同时avm和fre数值的比值悬殊很大，fre数值很小.38Sar查看系统活动状态信息查看系统所有活动状态信息39Topas哪个进程使用CPU最多40svmon

svmon命令用来查看系统当前的内存的具体使用 通过不同的选项参数，可以查看某个命令、进程、用户等使用内存的具体状态41errpt每个管理员例行查错命令列出错误日志的详细信息#errpt–a显示具体某个错误项的详细信息#errpt-a-jE18E984F42WeblogicTuning43WEBLOGIC的性能调整对于weblogic本身的堵塞，需要用threaddump来进行分析44如何观察weblogic性能Weblogic的java进程的cpu占用率一般不超过60%JVM的gc回收要正常，有负载时平均3-4秒回收一次即可，如过于频繁，会形成小锯齿，导致CPUboundWeblogic的executethread数目要足够，监控是否出现超出此线程数目的情况队列中空闲线程数。队列中等待时间最长的请求。队列长度，根据队列中等待请求数来衡量的。JVM堆还剩余的内存量。45Weblogic挂起的原因Hang即挂起，在weblogic中表现为运行weblogic的java进程还存在weblogic不响应请求weblogic请求处理很慢Weblogic挂起的原因系统内存不足系统CPU繁忙系统文件描述符不够线程死锁JVM有GC方面的bug其他原因（如Oracle）46如何调整weblogic的性能合理调整JVM的内存占用，一般单个JVM不要超过1GB为耗时较长的servlet或jsp创建单独的队列，而不是全部servlet或jsp使用同一个defult队列，如为清单查询，费用查询等耗时较长的servlet创建单独的队列为提高吞吐量，将JVM的内存最小值和最大值设成相等启用nativeIO，默认为启用（NativeIOEnabled=true）增加默认的defalut执行队列大小，我们的系统一般配成70左右，初始即为70不动态增加Servlet或jsp尽量少的在程序中组织数据，否则会极大地消耗JVM的内存和CPU，导致堵塞，如需要一个1万条数据的报表，这1万条数据在jsp中进行循环格式化会消耗大量的cpu当weblogic的性能监控界面显示有堵塞时，使用threaddump方法生成JVM的内部日志，并进行分析Threaddump结果中重点关注STATE：MW状态的servlet或jsp47Weblogic阻塞的判断和处理当前台无法登陆等问题出现时一般是由于weblogic阻塞察看weblogic的性能监控界面，发现等待的队列数一直在增加则表示weblogic产生堵塞JVM的gc回收过于频繁，如小锯齿形状或成一条近水平的直线，通常表示weblogic的整体性能很低下Threaddump是分析weblogic堵塞的最常用方法，通常每隔5-10秒执行一次，连续执行3-5次即可用使用javaweblogic.Admint3://server:portPING来ping该服务器。如果