《性能工程系列之一：性能测试篇.ppt》由会员分享，可在线阅读，更多相关《性能工程系列之一：性能测试篇.ppt（51页珍藏版）》请在三一文库上搜索。
1、性能工程系列之二,性能调优介绍,PQA测试部 2010年5月,议题,Oracle调优 Aix系统调优 WebLogic调优,调优被分成不同的阶段:,应用设计和开发 数据库配置 布署应用 故障解决和调优,调优基本原则,如果某个部分不是瓶颈，就不要尝试去优化 优化是为系统提供足够的资源并且充分的使用资源，而不是无节制的扩充资源 优化有时候也意味着合理的分配或者划分任务 优化可能会过头，注意协调整个系统的性能,Oracle Tuning,优化的基本方法,设立合理的性能优化目标 测量并记录当前性能 select system information 确定当前oracle的性能瓶颈（等待什么） 把等待事
2、件记录 确定当前的os瓶颈 优化所需的部分（应用程序、数据库、i/o、争用、os、存储、网络等） 跟踪并实施更改过程 测量并记录当前性能 重复3-7，直到满足优化目标,Oracle9i内存建议视图及参数,V$DB_CACHE_ADVICE V$SHARED_POOL_ADVICE V$PGA_TARGET_ADVICE db_block_size db_cache_size db_file_multiblock_read_count Processes sga_max_size,等待事件,两类等待事件： 空闲等待：oracle正在等待某种动作的发生 client message(客户机消息)；
3、 NULL event（NULL事件）； pipe get（管道取操作）； SQL*NET message from client（来自客户端的消息）； rdbms ipc message(数据库icp消息)等 非空闲等待事件：数据库发生了竞争 buffer busy waits(数据高速缓存忙等待)； db file scattered read(数据文件离散读取)； db file sequential read(数据文件顺序读)； enqueue(队列)、free buffer waits(空闲缓冲区等待)； latch free(拴空闲)； log file parallel writ
4、e(日志文件并行写入)； log file sync(日志文件同步)等,常见非空闲等待事件,buffer busy waits(数据高速缓存忙等待，多个进程在对一个块做操作) db file parallel write(数据文件并行写) db file scattered read(数据文件离散读取) db file sequential read(数据文件顺序读) db file single write(数据文件单次写) direct path read(直接路径读取) direct path write(直接路径写出) enqueue(队列) free buffer inspected
5、(空闲数据缓冲区探测) free buffer waits(空闲缓冲区等待) latch free(锁存器空闲) library cache load lock(库高速缓存装载锁),常见非空闲等待事件,library cache lock(库高速缓存锁) library cache pin(库高速缓存执行锁) log buffer space(日志缓冲区空间分配) log file parallel write(日志文件并行写入) log file single write(日志文件单次写)，提交频繁会出现 log file switch(archiving needed)归档没完成，造成lo
6、g write 不能覆盖， log file switch(checkpoint incomplete) log file sync(日志文件同步) timer in sksawat(归档过慢) Transaction(事务阻塞) undo segment extension(回滚段动态扩展，回滚段不停的动态扩展，事物大，事物长时间不结束),检查I/O统计的诊断,SQL select d.tablespace_name TABLESPACE, d.file_name, f.phyrds, f.phyblkrd, 2 f.readtim, f.phywrts, f.phyblkwrt, f.wr
7、itetim 3 from v$filestat f, dba_data_files d 4 where f.file# = d.file_id order by tablespace_name, file_name; TABLESPACE FILE_NAME PHYRDS PHYBLKRD READTIM PHYWRTS PHYBLKWRT WRITETIM - - - - - - - - USERS /u03/users01.dbf 65012 416752 38420 564 564 8860 SAMPLE /u02/sample01.dbf 8 8 0 8 8 0 SYSTEM /u0
8、1/system01.dbf 806 1538 1985 116 116 1721 TEMP /u04/temp01.dbf 168 666 483 675 675 0 1)Users有65012次读、564次写，而sample为8次读、8次写，说明数据分布不均衡把users中的表 movie到sample上 2)索引访问才8块，而数据访问为416752块,说明索引和表放在同一个表空间上 而没有放在索引表空间上 3)通过users可以看出,65012次读确读到了416752个块,说明单次读了多块,大概一个io读了6块,说明走 的是全表扫描,没有有效利用索引,索引一个io尽读一个块,因此索引有问
9、题,可能没有使用索引、可能 就要求全表扫描,system为806块,可能用户表放在这里了,或者发生解析需要用到数据字典信息。,索引-数据库加速利器,逻辑上 单列 / 组合索引 唯一 / 非唯一索引 物理上 分区或非分区 B 树 正常或反向键 位图,创建索引: 提示,平衡查询与DML操作的需求. 将索引放在单独的表空间. 对于大的索引考虑使用NOLOGGING. 索引的INITRANS应该比相应表的INITRANS设置的高一些. 插入操作导致在适当的块中插入索引项 删除行只导致逻辑删除索引项，删除的行所占用的空间难以用于新项，直到删除块中的所有项,所以对于更新和删除比较多的索引需要定期重建, 保
10、持索引的性能.,索引为何失效？,对索引字段进行计算 索引字段与数据类型不符合 不等于符号 对索引字段使用了函数(to_date,to_char) 查询数据选取范围过大 复合索引的前导列未被使用 字符可以转换成数字 优先级别高的使用索引,重建索引,SQL ANALYZE INDEX acct_no_idx VALIDATE STRUCTURE; Index analyzed.表的名称为indx_stats; SQL SELECT (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100 2 AS wastage 3 FROM index_stats; pct_used越低建议重建
11、WASTAGE - 24 如果Wastage20%就应该考虑重建！ SQL ALTER INDEX acct_no_idx REBUILD; Index altered.,索引可能降低查询性能,若查询数据比例占表数据百分比过大则降低性能 影响百分比大小的因素 IO能力 buffer cache 大小 数据有序度（dba_indexes. CLUSTERING_FACTOR ） 表数据行大小与block大小,优化模式,在Oracle9i, 两种优化模式可以被选择: 基于规则的 Rule-based: 使用一个分级系统 语法(Syntax)驱动和字典(dictionary)驱动的 Oracle从早
12、期版本提供RBO优化器，至Oracle10g该优化器不再被支持 基于代价的 Cost-based: 选择最低代价的路径 统计(Statistics)驱动,静态的统计信息 从Oracle7(1992)-Oracle10g主要支持的优化器,设置优化模式,在实例级: optimizer_mode = choose|rule|first_rows|first_rows_n| all_rows 在会话级: alter session set optimizer_mode = choose|rule|first_rows|first_rows_n| all_rows 在语句级: 使用提示(hints),S
13、oft parse and Hard parse,Soft parse 软解析，通过hash计算查找sql在共享池中存在于是重用执行计划的过程 Hard parse 硬解析，通过hash计算查找发现sql在共享池中不存在，于是重新产生执行计划的过程 软解析和硬解析对资源的消耗差异很大,SQL优化基本原则,减少重分析 合理使用索引 使用合理的表连接方式 减少不必要的排序 降低逻辑读,数据库共享池,为什么要使用共享池 SQL解析代价比较高 有限周期内系统一般运行大量重复代码 系统的sql数量总是有限的 合理的使用共享池能够降低重分析的次数 如何减少重分析的次数 配置足够大的共享池 采取统一的语句书
14、写规则 使用绑定变量 在不能使用绑定变量的基础上使语句实现代码共享,不使用绑定的影响,使用更多的共享池来缓存sql和执行计划 使用更多的cpu资源 将产生更多的数据库内部锁 导致共享池管理代价的增加,数据库对绑定的补救措施,Cursor_sharing = force/exact/similar 我们为什么还要强调在程序中绑定 cursor_sharing 存在bug cursor_sharing 影响sql执行计划 cursor_sharing 消耗额外内存和cpu 在应用中绑定的代价低，维护的代价很高 由数据库设置Cursor_sharing 风险很高,连接方式,合并连接（sort mer
15、ge join）: 是集合的合并操作，一般是在没有有效的索引时使用 循环嵌套连接（nested loop join）: 是一种循环的行操作，对于事务型处理是首选。在OLTP系统中常见，使用有效的索引来执行操作。 散列连接（hash join）: 使用连接表的全表扫描完成。 Oracle执行每个表的全表扫描，并根据内存情况，将每个表分成所需的多散列分区，然后通过另一个表的相应分区试探这个散列表。散列连接适合大表的连接。 注意设置合适的参数：hash_area_size和hash_mutilblock_io_count,RBO下Sql语句的优化规则,在RBO模式下，Sql语句的执行遵循着规则级别的
16、优先级： Single row by ROWID Single row by cluster join Single row by hash cluster key with unique key Single row by unique index Cluster join Hash cluster key Indexed cluster key Composite key Single-column non-unique index Bounded range search on indexed columns Unbounded range search on indexed colum
17、ns Sort-merge join MAX or MIN of indexed column ORDER BY on indexed columns Full table-scan,写SQL语句的一些提示,从I/O的观点来看，使用索引没有意义时建议使用全表扫描 如果查询中包含了子查询，那么注意首先优化子查询 注意关联子查询，尽量减少关联子查询的使用，因为它的代价很高，并且非常消耗CPU 在Sql语句中使用not exists 代替 not in 用表连接替换EXISTS 使用带有前导字段的like来替换substr函数 考虑使用union all代替多个or连接操作 如果经常执行主细表的联合
18、查询，建立外键索引 考虑使用非唯一索引支持唯一性约束条件,写SQL语句的一些提示,主动的确定使用循环嵌套、合并连接、散列连接，尽可能测试使用一种代价较小的连接方式。 如果需要在pl/sql 程序中使用动态sql，建议使用execute immediate 对于非常大的表，考虑使用表和索引的分区 如果需要在创建索引的时候减少所需时间，可以在会话集设置比较大的sort_area_size 考虑更多的使用decode函数，而不是在pl/sql中作判断 一定要周期性的收集信息，及时发现系统中的潜在问题,写SQL语句的一些提示,选择最有效率的驱动表 很多情况下ORACLE并不能为我们的SQL语句选择最有
19、效的驱动表, 在我们自己确定了合适的驱动表之后,可以使用HINT: ORDERED,LEADING来指定合适的驱动表 WHERE子句中的连接条件书写顺序 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾 减少对表的访问次数 （减少逻辑读） 避免索引列的类型 隐式转换造成的索引无效,AIX Tuning,AIX性能分析与故障诊断,掌握基本的性能调试工具 掌握基本的故障诊断工具,一般性能分析过程,CPU瓶颈？,内存瓶颈？,I/O瓶颈？,网络瓶颈？,vmstat ps lsps svmon,vmstat sar nice ps,iostat lslv filemon fileplace,
20、More test,netstat nfsstat,nfso no ifconfig netpmon,Y,Y,Y,Y,N,N,N,N,性能分析工具,iostat,vmstat,sar,topas,svmon,iostat,CPU的使用状态 % user，表示平均用户占用时间 % sys，表示系统花费CPU时间 % idle，表示CPU空闲时间 % iowait，表示CPU等待I/O所花费时间,iostat,分析： 如果%idle数值都很高而且%iowait数值也很高，大于25，这个说明系统存在I/O或 则硬盘瓶颈,内存不够而引起频繁的swap空间的数据交换，导致数据存取存在交换空间的 I/O瓶
21、颈 硬盘上面数据不合理的分布 数据的fragment不合理,高数值的%iowait有可能下面几个原因：,iostat,硬盘使用状态 % tm_act 表示某个硬盘处于active状态的百分比 tps 表示每秒某个硬盘有多少个数据传输次数 Kb_read Kb_wrtn 分别显示从开机到运行iostat这个命令这段时间内对 硬盘的read和write的总数据 量，单位kb,vmstat,CPU空闲时间百分比 = id % + wa % 算CPU平均一分钟空闲多少时间 (99929586+796)10056056.16(秒),vmstat,kthr 参数 r 等待CPU运行的队列个数 若r 数值偏
22、大，表明CPU太忙 b 等待I/O操作的阻塞队列个数 若b 数值偏大，表明系统I/O出现瓶颈,vmstat,CPU 瓶颈 如果sy 和us参数的数值加起来接近100，表示系统CPU使用率太高，同时也会看到r 的数值也大于1 内存瓶颈 内存不足，换页将变得频繁，这时pi(page-in )和po(page-out ) 参数将不是0，同时avm 和fre 数值的比值悬殊很大，fre 数值很小.,Sar,查看系统活动状态信息,查看系统所有活动状态信息,Topas,哪个进程使用CPU最多,svmon,svmon 命令用来查看系统当前的内存的具体使用,通过不同的选项参数，可以查看某个命令、进程、用户等使
23、用内存的具体状态,errpt,每个管理员例行查错命令,列出错误日志的详细信息 # errpt a 显示具体某个错误项的详细信息 # errpt -a -j E18E984F,Weblogic Tuning,WEBLOGIC的性能调整,对于weblogic本身的堵塞，需要用threaddump来进行分析,如何观察weblogic性能,Weblogic的java进程的cpu占用率一般不超过60% JVM的gc回收要正常，有负载时平均3-4秒回收一次即可，如过于频繁，会形成小锯齿，导致CPU bound Weblogic的execute thread数目要足够，监控是否出现超出此线程数目的情况 队列
24、中空闲线程数。 队列中等待时间最长的请求。 队列长度，根据队列中等待请求数来衡量的。 JVM堆还剩余的内存量。,Weblogic挂起的原因,Hang即挂起，在weblogic中表现为 运行weblogic的java进程还存在 weblogic不响应请求 weblogic请求处理很慢 Weblogic挂起的原因 系统内存不足 系统CPU繁忙 系统文件描述符不够 线程死锁 JVM有GC方面的bug 其他原因（如Oracle）,如何调整weblogic的性能,合理调整JVM的内存占用，一般单个JVM不要超过1GB 为耗时较长的servlet或jsp创建单独的队列，而不是全部servlet或jsp使用
25、同一个defult队列，如为清单查询，费用查询等耗时较长的servlet创建单独的队列 为提高吞吐量，将JVM的内存最小值和最大值设成相等 启用native IO，默认为启用（NativeIOEnabled=true） 增加默认的defalut执行队列大小，我们的系统一般配成70左右，初始即为70不动态增加 Servlet或jsp尽量少的在程序中组织数据，否则会极大地消耗JVM的内存和CPU，导致堵塞，如需要一个1万条数据的报表，这1万条数据在jsp中进行循环格式化会消耗大量的cpu 当weblogic的性能监控界面显示有堵塞时，使用thread dump方法生成JVM的内部日志，并进行分析
26、Thread dump结果中重点关注STATE：MW状态的servlet或jsp,Weblogic阻塞的判断和处理,当前台无法登陆等问题出现时一般是由于weblogic阻塞 察看weblogic的性能监控界面，发现等待的队列数一直在增加则表示weblogic产生堵塞 JVM的gc回收过于频繁，如小锯齿形状或成一条近水平的直线，通常表示weblogic的整体性能很低下 Threaddump是分析weblogic堵塞的最常用方法，通常每隔5-10秒执行一次，连续执行3-5次即可 用使用javaweblogic.Admin t3:/server:port PING 来 ping 该服务器。如果服务器
27、能够响应此 ping，则可能是应用程序正在挂起而不是服务器自身 C:javaweblogic.Admin -urlt3:/xxiong02:7001 -usernameweblogic -password weblogicPING 1 1 Sending 1 ping of 1 byte.RTT = 21 milliseconds, or 21 milliseconds/packet,Weblogic阻塞的判断和处理,如果执行队列有空闲线程，则可能是没有分配足够的Socket Reader 线程。 Socket Reader 线程接受来自ListenThread 队列的传入请求，并将该请求放入
28、ExecuteThread队列中。 如果Thread Dump 中没有Socket Reader 线程，则在某个地方存在导致Socket Reader 线程消失的错误。应当始终保持至少有三个Socket Reader 线程。一个Socket Reader 线程一般用于轮询功能，另外两个用于处理请求。 缺省情况下，WebLogicServer实例在启动时创建三个Socket Reader 线程。如果一个Cluster system在高峰期使用的Socket Reader 线程超过三个，则增加Socket Reader 线程的数量。 ThreadPoolPercentSocketReaders属性设定要用于从java Socket 中读取消息的执行线程的最大百分比。此属性的最佳值是针对应用程序设定的。缺省值为33，有效范围是1 到99,Weblogic阻塞的判断和处理,在系统运行过程中出现weblogic hang的情况，通常我们要 首先检查操作系统是否出现内存和cpu bound 确认tuxedo端有无堵塞，如tuxedo有堵塞，首先确认是否数据库端导致此堵塞 数据库端导致的tuxedo堵塞常见有锁的问题，执行效率低下的问题等 如tuxedo端无堵塞，对java进程执行kill -3生成thread dump进行分析,谢 谢！,