Oracle RWP大开眼界系列笔记

发现一个非常好的公益课，是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行的，通常这个驱动表预估行数应该是错的