Oracle Resource Management

RWP团队谈性能优化之大开眼界篇（三）资源管理

您觉得，在什么情况下需要进行资源管理？

A. OLTP

B. 报表查询

C. 混合工作负载

D. 什么情况都需要

E. 什么情况都不需要

资源管理是在任何情况都需要考虑的，可以使用的方法也很多

首先讨论了工作负载的类型。

OLTP类型的工作负载，特点是并发用户数多，SQL语句一次处理的数据量少。

报表查询类型的工作负载，特点是并发用户数少，通常是数据密集型查询处理大量数据。

数据加载与处理类型的工作负载，特点是并发用户数少，DML处理大量数据。

接下来讨论了混合工作负载的调整策略。系统上资源是有限的。内存资源的竞争一定要避免，因为只要内存不够啦，出现争抢内存的情况，结果肯定都是很糟糕。处理网络和存储相关的操作，也是使用CPU。所以限制了CPU资源的使用，也会限制网络和存储资源的使用。所以资源管理，管理的资源，最重要的是CPU资源。

对于OLTP类型的工作负载来说，想要性能好，系统上CPU使用率不要超过60-70%这个区间

对于混合工作负载，资源管理的目标和CPU策略都是对立的。OLTP的目标是快速的响应时间，CPU策略是最小化，就是系统上要有空闲CPU。报表查询和数据加载与处理类型的工作负载，因为需要处理大量数据，吞吐量是很重要的目标，CPU策略是最大化，就是尽量用到更多的CPU资源，才能性能好

管理混合工作负载，有很多方法。

可以不同的负载跑在不同的数据库上，也可以是不同的负载跑在同一个数据库上。

如果是不同的负载跑在不同的数据库上，那么一个办法就是为每个工作负载分配虚拟机。每个工作负载不能使用超过分配的CPU

另一个办法是，让所有工作负载跑在同一个操作系统上，这时候为数据库启用资源管理计划，用instance caging来控制单个数据库使用的CPU，通过CPU_COUNT参数定义每个数据库能最多能使用多少CPU资源

还有一个办法是，使用多租户，让每个工作负载跑在一个独立的PDB上，然后在CDB上启用资源管理计划来控制各个PDB的CPU使用

如果是不同的工作负载跑在同一个数据库上，那么一个办法是，让每个工作负载使用一个不同的RAC

service，然后将RAC service映射到不同的RAC节点。

如果是不同的工作负载跑在一个数据库实例上，那么可以使用DBRM，将不同的工作负载映射到不同的consumer group上，然后通过shares或者Limits来制定每个consumer group可以用到的资源。

使用DBRM的话，如果使用shares来分配资源，要注意shares的意思是共享的，是个软限制，如果consumer group 1没有用满设定比例的资源，那么在需要的时候consumer

group 2是可以超额使用的。另外shares是通过比例来分配的，比如consumer group 1分配3个share，consumer group 2分配1个share，那么就是当系统很忙的时候，consumer group 1可以使用3/（3+1）=75%的资源，consumer

group 2可以使用1/（3+1）=25%的资源

使用DBRM的话，如果使用Limits来分配资源，那么就跟字面意思一样，是限制，或者说是个硬的限制。即便系统有空闲资源，任何consumer group 使用的资源都不能超过其Limits设置的值

对于并行查询，Parallel Statement Queuing是个非常有用的资源管理工具。Parallel Statement Queuing最基本的思想是，并行查询去到先进先出的队列里面，让每个并行查询尽量按照请求的DoP去执行，不要降级。Parallel Statement Queuing可以和DBRM配合使用，将不同优先级的报表查询放到不同的consumer group里面（每个consumer group会有自己的先进先出队列），为每个consumer group指定可以使用的PX server的数量

总之，结合上述的不同的方法，可以开发出更复杂更适合你的实际情况的CPU使用策略和资源管理计划

接下来进行了demo。Demo的情况是，OLTP，报表查询，ETL，这三种类型的工作负载，跑在一个服务器的一个数据库上。

在demo系统上分别介绍了上述三种工作负载。

对于OLTP工作负载，Think Time=4000 代表低工作负载，Think Time=500 代表峰值工作负载。系统上只跑OLTP工作负载，在峰值工作负载的时候，OLTP CPU使用率大概30%。OLTP工作负载是demo的情景下的关键的工作负载，就是说，要保证OLTP工作负载的吞吐量和响应时间。这和现实中大多数混合工作负载的场景类似，OLTP工作负载通常是关键的，需要被保护的那个

对于报表查询工作负载，查询的并行度是8。只有1个用户跑查询的时候是低工作负载，8个用户跑查询的时候是峰值工作负载

对于ETL工作负载，并行度为16代表预期的工作负载，循环跑数据装载、去重、转换和汇总四个操作

在介绍完报表查询和ETL工作负载之后，将OLTP工作负载从低负载逐渐加大到峰值工作负载，OLTP的响应时间大幅变慢，TPS比单独跑OLTP工作负载的时候低很多。就是说，关键的OLTP工作负载的性能，被报表查询和ETL工作负载影响了

这个时候我们启用了DBRM，使用Limits法，将报表查询工作负载的CPU使用率限制为15%，将ETL工作负载的CPU使用率限制为10%，这个时候可以看到关键的OLTP工作负载的响应时间大幅变快了

注意到，这个时候，峰值OLTP工作负载，OLTP部分使用到的CPU是大概40%，而单独跑峰值OLTP工作负载的时候，CPU使用率只有大概30%。类似现象在低OLTP工作负载的时候也被观察到了。这说明，系统越忙的时候，CPU的使用效率会相对差，完成同样的工作，需要消耗更多的CPU资源。OLTP类型的工作负载对CPU又尤其敏感，所以这里我们看到被报表查询和ETL工作负载影响之后，OLTP工作负载需要花比原来多大约30%（ （40%-30%）/30% ）的CPU资源才能在性能保持基本一致的情况下完成同样强度的工作

总结

如果是混合工作负载，跑在同一个服务器的同一个数据库上，需要保护其中关键的OLTP工作负载，可以参考demo的方法 – 使用DBRM，不要限制关键的OLTP工作负载，确定只跑OLTP的情况下，峰值OLTP工作负载的CPU使用率，然后用下面的公式来估算可用于其他工作负载的CPU：

60~70 – ((OLTP CPU %) * 1.3) = 可用于其他工作负载的CPU

举个例子假设只跑OLTP的时候，峰值 CPU 使用率 30%下限：60 – ((30* 1.3) = 其他工作负载可使用小于 20% 的CPU上限：70 – ((30* 1.3) = 其他工作负载可使用小于 30% 的CPU用下限还是上限就是看你想要更保守一些，还是更激进一些。

总之呢，只有适当的限制了其他工作负载的CPU使用率，才能避免其他工作负载对关键的OLTP工作负载的影响，才能保护OLTP工作负载的性能。

当然，资源管理是一个很大的话题。Demo的场景只是给大家举了很多可能的场景中的一个例子，希望以此能够提高大家对资源管理这个事情的重视和思考。

如果实际情况是，白天OLTP是关键的工作负载，晚上报表查询和ETL是关键工作负载，那么可以在白天和晚上使用不同的资源管理计划。在数据库里面更换资源管理计划是非常简单容易的事情

1. 在只跑OLTP的时候，峰值CPU使用率70%，设定系统中可用于其他工作负载的CPU总计多少比较合适？0%10%20%30%

如果峰值CPU使用率70%的话，那么引入其他的工作负载，就会对OLTP的性能造成影响。所以如果想要保护OLTP的性能的话，0%在此是合适的

2. 在只跑OLTP的时候，峰值CPU使用率30%，设定系统中可用于其他工作负载的CPU总计多少比较合适？10%30%50%70%

按照总结里面的公式计算

70– ((30* 1.3) = 其他工作负载可使用小于 30% 的CPU

所以30%在此是比较合适的。10%的话，对OLTP的性能不会造成影响，但是会导致系统的资源没有被充分的利用。50%和70%对OLTP的性能就会造成影响了，大家也可以回看视频来回顾一下其他工作负载对OTLP工作负载的性能的影响

3. 您觉得，在什么情况下需要进行资源管理？ OLTP报表查询混合工作负载什么情况都需要

什么情况都不需要

什么情况都需要进行资源管理。还是那个，资源管理是个很大的话题，使用DBRM的Limits法来保护跑在同一个服务器上的同一个数据库里的多个工作负载中的关键的OLTP工作负载，只是诸多场景中的一个，用的也只是诸多方法中的一个。资源管理这个事，在任何情况都要考虑，具体方法也可以有很多