发现一个非常好的公益课,是Oracle RWP团队介绍性能优化的常用技巧,视频链接 https://space.bilibili.com/28628293/video?tid=0&page=1&keyword=&order=pubdate
一、 连接池策略
每个连接是一个server process
连接池最大值是不是应该越大越好?为什么?
当然不是,这只考虑了应用端
1. 初始:连接池连接数最大288,thinktime=10s
2. 连接池连接数修改为最小288最大6000,thinktime=5s -> tps与active session翻倍,响应时间变化不大(因为负载还是很低)
3. Thinktime改为2.5s,出现明显波峰,但大多数时间较稳定。绿色为等待获得连接时间。
4. Thinktime改为600ms,active session、响应时间明显上升,tps反而下降,cpu峰值将近80%,后稳定在40%左右
活跃会话出现大量异常等待
一段时间后系统看似又恢复了,但其实是很不稳定的
5. Thinktime改为300ms,active session飙升,tps震荡,系统明显更不稳定
6. 减少连接数至288,tps升高,响应时间及活跃会话明显下降
降低连接数tps变高的原因
6000连接是将连接压到里数据库层来排队,将近6000进程等待处理,争抢太过(有IO没cpu,有cpu没latch等等等等),大家等待时间都长,等待其他资源时在spin空转,白白消耗CPU。并且要浪费大量资源进行进程调度,cpu cache命中率大大降低,浪费资源。288连接时连接是压在应用或连接池,数据库负载依然不太高,有更多资源处理实际请求,大家等待时间较短,因此cpu及响应时间低。
连接数设置建议
初始:1~10倍数据库cpu核数,依据负载而定
连接数应该服务于tps而不是先考虑连接数最大能设多少,连接数多不等于性能好。即,进程数设置应该考虑cpu数而不是应用用户数,因为最终是由硬件来决定的。
Thinktime改为0会如何?
响应时间增加,tps活跃会话变化不大(因为之前活跃连接也是满的)
负载其实已经到数据库瓶颈,需要新增cpu才能增加tps
Processes是数据库进程数上限,本节讨论的是应用连接池的设置,两个并不一样,Processes可以设大些因为不一定能用上,而且修改是要重启数据库的。
连接池中间件的优化通常是指会提前创建更多连接,可能造成连接风暴问题。连接越多,每个进程可分配到的pga内存越少,每个进程也会占用一些内存造成浪费。
二、 应用程序算法篇
测试不同array size 插入350w行数据时间,无网络延迟
修改网络延迟为1~3ms
能用array就用,但并不是size越大越好
Array(一个进程) vs 手工并发(手动起96个应用进程进行row by row操作)
插入2kw行,可以看到后者慢,而且出现大量异常等待
表有索引情况对比,前者变化不大,后者出现更多类型异常等待
或者用多表insert
各种方法插入速度比较
第三种改为手工并发+array
执行结果
加载数据
去重+加载数据
数据转换+加载数据
第三种慢了是由于代码过于复杂了
三、 资源管理
四、 AWR实例分析
注意cores数,不建议会话数过多
ADDM告诉你哪部分最可能有问题,占比多少(12c开始才有)
dbtime就是所有会话活跃+等待时间,每秒有dbtime 2800多说明等待一定非常多,因为cpu core才48个。
每秒DB CPUs 是每秒on CPU的进程数,58超过了cpu core数,说明此时到达了cpu瓶颈。
User logins OLTP在稳定时应该接近于0
初始化参数决定了数据库到底是怎么使用的
隐含参数要引起重视,不要随意设置,每个版本其定义可能变化。即使是修复bug的workaround,修改时应该记录,打完补丁之后隐含参数应该改回去
等待事件avg wait是等待相应资源的时间+等CPU的时间,如果系统资源有问题应该先看资源。
应该直接做表关联而不是取出长长的list放在in里
一个例子
- 版本较老
- Cores为32,会话数设置过大,且在awr结束时会话还增加了1000多,有连接风暴风险
- Dbtime高,cpu负载高
- Cursors数在awr结束时还增加了,可能有游标泄漏的问题
- 每秒dbtime和db cpus高,应该存在cpu瓶颈,有大量异常等待
- 每秒硬解析不多,logins很多,每秒10.5个,每个小时会达到36000多个,可能符合前面连接风暴的猜测
- 每秒1300多个事务,其中878个是回滚的,大量无用功
明显设置了大量隐含参数,cursor_sharing是force,db_block_size是16k,更大的块大小并不能让IO吞吐量更大
每个会话设置了可以打开2000个游标,可能代码有游标泄漏问题
优化器相关参数
参数越多,数据库越独一无二,碰到的问题也可能独一无二
会话越多出现资源等待可能性越高,进程调度资源消耗越高。对于IO等待,应该判断AVG WAIT时间是否合理
Top 1总时间多但%cpu和io很少,说明遇到的异常等待可能相当多
可以看到有大量行锁
Top 2,3是监控语句,执行超过2600万次,消耗cpu接近13%,是否值得?
务必注意awr的时间是否是故障时间,应该还附上正常时候的awr,方便排查。
标准化,最好传awr或者官方工具而不是自己开发的工具。否则别人既要花时间重新理解,也无法保证收集的语句是对的。
对于Rac数据库,应该生成全局的awr(下图),以及每个rac节点上的awr信息
连接管理明显异常
如何找历史回滚事务信息
五、 Sql monitor篇
11.1版本开始引入,数据库内部组件,可在sql执行期间就监控
Txt格式看不到过滤条件信息
所谓“好的”不是完全没有差异,是没有数量级的差异
预估行数是0~1范围内都会显示1,因为为0后面cost无法计算
如果一个表或视图执行次数是5000,join为nest loop join,可以去找其驱动表有没有预估行数是1实际返回是5000行的,通常这个驱动表预估行数应该是错的
预估行数是0~1范围内都会显示1,因为为0后面cost无法计算
如果一个表或视图执行次数是5000,join为nest loop join,可以去找其驱动表有没有预估行数是1实际返回是5000行的,通常这个驱动表预估行数应该是错的