Pool de recursos do Resource Governor

Aplica-se a: SQL Server Instância Gerenciada de SQL do Azure

No Resource Governor do SQL Server, um pool de recursos representa um subconjunto dos recursos físicos de uma instância do mecanismo de banco de dados. O Administrador de Recursos permite que você especifique os limites de quantidade de CPU, E/S física e memória que as solicitações recebidas de aplicativos podem usar dentro do pool de recursos. Cada pool de recursos pode conter um ou mais grupos de cargas de trabalho. Quando uma sessão é iniciada, o classificador do Administrador de Recursos atribui a sessão a um grupo de cargas de trabalho específico e a sessão deve ser executada, usando os recursos atribuídos ao grupo de cargas de trabalho.

Conceitos do pool de recursos

O pool de recursos ou pool representa os recursos físicos do servidor. Pense no pool como uma instância virtual do SQL Server dentro de uma instância do SQL Server. Um pool tem duas partes. Uma parte não sobrepõe outros pools, permitindo reserva mínima de recursos. A outra parte é compartilhada com outros pools, fornecendo suporte ao consumo máximo possível de recursos. Os recursos do pool são definidos especificando-se uma ou mais das seguintes configurações para cada recurso (CPU, memória e E/S física):

MIN_CPU_PERCENT e MAX_CPU_PERCENT

Essas são as configurações mínima e máxima de largura de banda de CPU garantida para todas as solicitações no pool de recursos quando há contenção de CPU. Você pode usar essas configurações para estabelecer o uso de recursos previsível de CPU para várias cargas de trabalho com base nas necessidades de cada carga de trabalho. Por exemplo, suponha que os departamentos de Vendas e Marketing em uma empresa compartilhem o mesmo banco de dados. O departamento de Vendas tem uma carga de trabalho com uso intensivo de CPU com consultas de alta prioridade. O departamento de Marketing também tem uma carga de trabalho com uso intensivo de CPU, mas tem consultas de prioridade inferior. Ao criar um pool de recursos separado para cada departamento, você poderá atribuir um percentual mínimo de CPU de 70 para o pool de recursos de Vendas e um percentual máximo de CPU de 30 para o pool de recursos de Marketing. Essa configuração garante que a carga de trabalho de Vendas receba os recursos de CPU necessários e que a carga de trabalho de Marketing seja isolada das demandas de CPU da carga de trabalho de Vendas. O percentual máximo de CPU é um máximo oportunista. Se houver capacidade de CPU disponível, as threads de trabalho usaram toda a capacidade, até 100%. O valor máximo só será aplicado quando houver contenção para recursos da CPU. Nesse exemplo, se a carga de trabalho de Vendas for desativada, a carga de trabalho de Marketing poderá usar 100 por cento da CPU se for necessário.

CAP_CPU_PERCENT

A configuração CAP_CPU_PERCENT é um limite rígido da largura de banda de CPU para todas as solicitações no pool de recursos. As cargas de trabalho associadas ao pool podem usar a capacidade da CPU acima do valor de MAX_CPU_PERCENT, quando está disponível, mas não acima do valor de CAP_CPU_PERCENT. Com base no exemplo da seção anterior, suponhamos que o departamento de Marketing esteja sendo cobrado pelo uso do recurso. Eles querem uma cobrança previsível e não querem pagar por mais de 30% da CPU. É possível atingir essa meta definindo o CAP_CPU_PERCENT para 30 para o pool de recursos de Marketing.

MIN_MEMORY_PERCENT e MAX_MEMORY_PERCENT

Essas configurações são a quantidade mínima e máxima de memória reservada para o pool de recursos que não pode ser compartilhada com outros pools de recursos. Para bancos de dados sem tabelas com otimização de memória, a memória referenciada é memória de concessão de execução da consulta, não memória do pool de buffers (dados e páginas de índice). Veja mais informações sobre concessões de memória de execução de consulta em Considerações de concessão de memória. Definir um valor mínimo de memória para um pool garante que o percentual de memória especificada esteja disponível para todas as solicitações que sejam executadas nesse pool de recursos. Esta configuração é diferente de MIN_CPU_PERCENT, porque, nesse caso, a memória poderá permanecer no pool de recursos determinado mesmo quando o pool não tiver nenhuma solicitação nos grupos de carga de trabalho que pertencem ao pool. Então, tenha cuidado ao usar essa configuração, pois essa memória não está disponível para uso por nenhum outro pool, mesmo quando não há solicitações ativas. Definir um valor máximo de memória para um pool significa que, quando as solicitações são executadas nesse pool, elas nunca obtêm mais do que essa porcentagem de memória total.

Para controlar a memória para tabelas com otimização de memória com o Resource Governor, associe o banco de dados a um pool de recursos separado. Para obter mais informações, confira Associar um banco de dados com tabelas com otimização de memória a um pool de recursos.

AFFINITY

Essa configuração permite relacionar um pool de recursos a um ou mais agendadores ou nós NUMA a fim de obter um maior isolamento de recursos de CPU. Para usar o cenário de Vendas e Marketing das seções anteriores, vamos supor que o departamento de Vendas precise de um ambiente mais isolado e queira 100% do núcleo de uma CPU constantemente. Usando a opção AFFINITY, as cargas de trabalho de Vendas e Marketing podem ser agendadas em CPUs diferentes. Supondo que o CAP_CPU_PERCENT no pool de Marketing ainda esteja ativo, a carga de trabalho de Marketing continuará a usar um máximo de 30 por cento de um núcleo, enquanto que a carga de trabalho de Vendas usará 100 por cento do outro núcleo. Do ponto de vista das cargas de trabalho de Vendas e Marketing, elas são executadas em dois computadores isolados.

MIN_IOPS_PER_VOLUME e MAX_IOPS_PER_VOLUME

Essas configurações são as operações de E/S mínima e máxima por segundo (IOPS) por volume de disco para um pool de recursos. Você pode usar essas configurações para controlar as E/S físicas emitidas para threads de usuário para um determinado pool de recursos. Por exemplo, o departamento de Vendas produz vários relatórios de fim de mês em lotes grandes. As consultas nesses lotes podem gerar entradas e saídas que podem saturar o volume de disco e afetar o desempenho de outras cargas de trabalho de prioridade mais alta no banco de dados. Para isolar essa carga de trabalho, o MIN_IOPS_PER_VOLUME é definido como 20 e o MAX_IOPS_PER_VOLUME é definido como 100 para o pool de recursos do departamento de Vendas. Essas configurações controlam o nível de entradas e saídas que podem ser emitidas para a carga de trabalho.

Pools de recursos definidos pelo sistema e pelo usuário

O Administrador de Recursos define previamente dois pools de recursos, o interno e o padrão. Você pode criar outros pools.

Pool interno

O pool interno representa os recursos utilizados pelo próprio SQL Server. Esse pool sempre contém apenas o grupo interno, e o pool não pode ser modificado de forma alguma. O consumo de recursos do pool interno não é restrito. Todas as cargas de trabalho do pool são consideradas críticas para a função do servidor. Então, o Resource Governor permite que o pool interno pressione os outros pools, mesmo se isso significar violação dos limites definidos para os outros pools.

Pool padrão

O pool padrão é o primeiro pool definido previamente pelo usuário. Antes de qualquer configuração, o pool padrão só contém o grupo padrão. Não é possível criar nem descartar o pool padrão, mas é possível alterá-lo. O pool padrão pode conter grupos definidos pelo usuário além do grupo padrão. A partir do SQL Server 2016 (13.x), há um pool de recursos padrão para operações de rotina do SQL Server e um pool de recursos externos padrão para processos externos, como a execução de scripts R.

Pool externo

Os usuários podem criar um pool externo para definir recursos para os processos externos. Para Serviços de R, esse pool controla especificamente rterm.exe, BxlServer.exe e python.exe outros processos gerados por eles. Para obter mais informações, veja CREATE EXTERNAL RESOURCE POOL

Pools de recursos definidos pelo usuário

Os pools de recursos definidos pelo usuário são aqueles que você cria para cargas de trabalho específicas em seu ambiente. O Administrador de Recursos fornece instruções DDL para criar, alterar e descartar pools de recursos. Veja mais informações em Criar um pool de recursos, Excluir um pool de recursos e Alterar configurações do pool de recursos.

Alocação de recursos entre pools

Ao configurar CPU ou a memória, a soma dos valores MIN de todos os pools não pode ultrapassar 100% dos recursos do servidor. Além disso, ao configurar CPU ou memória, os valores MAX e CAP podem ser definidos em qualquer lugar no intervalo entre MIN e 100 por cento inclusive.
Se um pool tiver um MIN diferente de zero definido, o valor MAX efetivo de outros pools será reajustado. O mínimo do valor MAX configurado de um pool e a soma dos valores MIN de outros pools é subtraído de 100%.

A tabela a seguir ilustra alguns dos conceitos anteriores. A tabela mostra as configurações para o pool interno, para o pool padrão e para dois pools definidos pelo usuário.

As fórmulas a seguir são usadas para calcular o MAX% efetivo e o percentual compartilhado na tabela:

• Min(X,Y) significa o menor valor de X e Y.

• Sum(X) significa a soma do valor X de todos os pools.

• % compartilhado total = 100 - sum(% MIN).

• % MAX efetivo = min(X,Y).

• % compartilhado = % MAX efetivo - % MIN.

Usando a tabela anterior como exemplo, podemos ilustrar mais tarde os ajustes que são feitos quando outro pool é criado. Esse é o Pool 3 e tem o valor 5 de configuração de % MIN.

A parte compartilhada do pool é usada para indicar aonde os recursos disponíveis podem ir se os recursos estão disponíveis. Porém, ao serem consumidos, os recursos vão para o pool especificado e não são compartilhados. Esse comportamento pode melhorar a utilização de recursos nos casos em que não há solicitações em determinado pool, e os recursos configurados para o pool podem ser liberados para outros pools.

Estes são alguns casos extremos de configuração de pool:

• Todos os pools definem mínimos que, totalizados, representam 100% dos recursos do servidor. Nesse caso, os máximos efetivos são iguais aos mínimos. Isso equivale a dividir os recursos do servidor em partes que não se sobrepõem, não importa se os recursos são utilizados em cada pool específico.

• Todos os pools têm mínimo com valor zero. Todos os pools disputam os recursos disponíveis e seus tamanhos finais baseiam-se no consumo de recurso em cada pool. Outros fatores, como políticas, desempenham uma função na formação do tamanho final do pool.

Tarefas do pool de recursos

Confira também

• Resource Governor
• Grupos de carga de trabalho do Resource Governor
• Função de classificação do Administrador de Recursos
• Configurar o Resource Governor usando um modelo
• Exibir Propriedades do Administrador de Recursos