Introdução
A consolidação de vários bancos de dados Oracle dentro de um único servidor ou cluster é algo cada vez mais comum, principalmente com o crescimento dos ambientes com Engineered Systems da Oracle, onde é natural migrar bancos de dados de vários servidores físicos ou virtuais para um único ambiente compartilhado, de modo a extrair o máximo do investimento.
O gerenciamento de memória de uma instância Oracle já é algo bem disseminado entre os administradores de banco de dados, item este que sempre evoluiu muito de uma versão para outra, deixando o gerenciamento cada vez mais automatizado e diminuindo o esforço administrativo do DBA. Hoje em dia, uma instância é comumente provisionada com um limite máximo de memória (SGA + PGA) e as coisas costumam fluir bem (quando bem dimensionado).
O gerenciamento de CPU, por outro lado, não é algo que é comumente configurado em muitos ambientes. Os motivos variam, desde o fato de ser uma funcionalidade do Enterprise Edition, ou por não ter havido um evento que demandasse um controle melhor deste recurso ou até mesmo desconhecimento da existência desta funcionalidade do Oracle Database.
O nome da funcionalidade que permite controlar o uso de CPU por uma instância Oracle é Instance Caging. A configuração é relativamente simples, bastando apenas configurar o parâmetro CPU_COUNT com um valor inferior a quantidade de CPUs no servidor, e por fim definir um plano do Oracle Database Resource Manager (DBRM).
Na prática, quem faz todo o trabalho é o DBRM, monitorando a utilização de CPU das sessões no banco de dados e forçando um wait de CPU quando o limite definido por CPU_COUNT for atingido. Nesse cenário, o DBRM irá gerenciar uma fila de CPU internamente para as sessões daquela instância.
Tipos de Configuração
Ao definir os limites de cada instância no servidor e configurar o Instance Caging em cada uma delas, temos a opção de usar a estratégia “Partition” ou “Over-provisioning”.
Partition
Os limites são definidos para cada instância de modo que a soma delas não ultrapasse a quantidade total de CPU disponível no servidor. O Oracle vai limitar aquela quantidade exata de CPU, essa estratégia protege o servidor de sofrer com cargas elevadas na CPU (mais processos na fila do que a CPU pode atender sem apresentar gargalo).
Exemplo: Servidor tem 32 CPUs, a instância tem CPU_COUNT=4 –> Ele vai ser limitado a usar 4 CPUs, independente da carga geral do servidor.
Over-provisioning
Os limites são definidos para cada instância de modo que a soma pode ultrapassar a quantidade total de CPU disponível no servidor. Na prática, o Oracle não utilizará o valor como um limite absoluto, mas fará uma proporção sobre o total, e o limite prático vai ser um % sobre o total de CPU disponível no servidor.
Exemplo: O servidor tem 32 CPUs, a instância tem CPU_COUNT=4, mas a soma total de todas as instâncias é 50. Neste cenário o DBRM vai usar como referência 4/50, o uso de CPU vai ser limitado a 8% (4/50*100) de 32, que equivale a 2.56 CPUs. Claramente não existe 2,56 CPUs, tecnicamente o gerenciamento é feito baseado em ciclos de CPU.
A Figura 1, retirada do documento “Database Instance Caging: A Simple Approach to Server Consolidation” ilustra a configuração do Instance Caging em um servidor com 32 CPUs distribuídas entre 4 instâncias de banco de dados, utilizando a estratégia Partition.
Configuração
Como mencionado anteriormente, a implementação do Instance Caging se dá pela configuração do parâmetro CPU_COUNT em conjunto com DBRM. Para habilitar o DBRM, basta definirmos um Resource Plan no parâmetro RESOURCE_MANAGER_PLAN, no exemplo abaixo estamos usando o plano padrão do banco de dados:
-- define limite de 4 CPUs
SQL> ALTER SYSTEM SET cpu_count = 4;
-- define o DEFAULT_PLAN como plano do DBRM
SQL> ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_PLAN';
Em um Container Database, o default plan do CDB é DEFAULT_CDB_PLAN:
SQL> ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_CDB_PLAN';
Para consultar os planos de Resource Manager existentes no banco de dados:
-- em non-CDB
SQL> SELECT PLAN FROM DBA_RSRC_PLANS;
-- em CDB
SQL> SELECT PLAN FROM CDB_CDB_RSRC_PLANS;
Em um Oracle Database Appliance (ODA), cada template utilizado para criar um novo banco de dados tem um shape que determina a quantidade de recursos computacionais que será empregado no banco de dados sendo criado. Por padrão, cada banco de dados é pré configurado com o parâmetro CPU_COUNT de acordo ao template utilizado. No entanto, o Database Resource Manager pode não vir habilitado por padrão, então para habilitar o Instance Caging nesses cenários, basta configurar o parâmetro RESOURCE_MANAGER_PLAN.
Instance Caging em Oracle RAC
Oracle Real Application Clusters (RAC) é a feature que permite clusterizar o banco de dados Oracle, onde múltiplas instâncias do mesmo banco de dados ficam online em servidores (nodes) separados. Oracle Instance Caging atua a nível de instância, o que significa que em um ambiente com Oracle RAC, o limite definido no parâmetro CPU_COUNT aplica-se as instâncias em cada node de forma individual.
Conforme ilustração na Figura 2, se o parâmetro CPU_COUNT for configurado com valor 2 em um cluster com 2 nodes, cada instância poderá usar 2 CPUs em seus respectivos nodes, o que totalizam 4 CPUs para o banco de dados como um todo.
Recomendações
Esta seção lista as principais recomendações da Oracle para configuração de Instance Caging, conforme nota 1362445.1.
- Ao adotar a abordagem Over-provisioning, use no máximo 3x o número de CPUs no servidor. Por exemplo: Se o servidor tem 24 CPUs, a soma do parâmetro CPU_COUNT em todas as instâncias não deveriam exceder o valor de 72.
- Evite alterar o parâmetro CPU_COUNT com muita frequência, pois essa operação tem um certo custo de processamento.
- Evite usar CPU_COUNT com valor igual a 1.
- Evite realizar alteração de um valor muito baixo para um valor muito alto, é recomendo aumentar o limite de forma gradativa e monitorar a carga no servidor.
Casos de Uso
Os exemplos a seguir demonstram a efetividade do Instance Caging em 2 ambientes diferentes, ambos são casos reais
Exemplo 1:
Neste primeiro exemplo, tínhamos um Oracle Database Appliance X8 com deploy misto, com bases produtivas e não produtivas. Instance Caging foi implementado de forma pró-ativa, para evitar que um problema de performance ocorresse caso houvesse uma demanda de processamento elevada pelas bases de homologação que pudessem impactar no desempenho da base de produção.
Nessa visão do Active Session History (ASH), podemos ver um efeito imediato no comportamento das sessões ativas assim que o parâmetro CPU_COUNT foi alterado com valor igual a 2. Os eventos de espera do DBRM são classificados como “Scheduler” e o evento de espera propriamente dito é “resmgr: cpu quantum”. Então se você ver sessões no banco de dados com evento de espera descrito como “resmgr: cpu quantum”, é indicativo de controle de CPU pelo DBRM.
Exemplo 2
Neste segundo exemplo, tínhamos um Oracle Exadata Cloud at Customer X7 consolidando diversas bases produtivas. Mesmo com uma certa quantidade de bancos de dados executando concorrentemente, o ambiente apresentava uma boa performance. Em um determinado momento, uma mudança em uma das aplicações que não era considerada uma das mais importantes para o negócio, começou demandar muito mais CPU do que o normal, elevando drasticamente a carga nos servidores e impactando no desempenho dos outros bancos de dados no mesmo cluster.
Aqui o Instance Caging foi implementando de forma reativa, como um meio de conter a demanda de CPU da instância problemática, protegendo o cluster como um todo e evitando que os demais bancos de dados apresentassem lentidão por conteção de CPU.
O gráfico mostra um crescimento anormal da média de sessões ativas na instância pouco antes das 08:00h, todas elas consumindo CPU. Durante um período de alguns minutos, a instância foi desligada para estabilizar a carga no servidor e em seguida iniciamos como Instance Caging habilitado. Neste cenário, ainda havia uma alta demanda de sessões ativas na instância, mas o uso de CPU foi controlado pelo Instance Caging de forma efetiva.
Neste cenário, mesmo levando um bom tempo até que identificassem a causa raiz de a aplicação estar com um número de sessões ativas muito acima do normal, o desempenho geral do ambiente foi protegido pelo uso do Instance Caging.
Conclusão
Este artigo apresentou uma introdução ao Oracle Database Instance Caging, assim como realizar a sua configuração levando em consideração um ambiente Single Instance e Oracle RAC. Por fim, foram apresentados dois casos de uso da funcionalidade com implementações no mundo real, demonstrando a efetividade de mais um dos recursos do Oracle Database de nível Enterprise projetado para atender a demanda do mercado em consolidar múltiplas cargas de trabalho em um único ambiente.