Resource Governor Pool de Recursos

No Administrador de Recursos 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 Resource Governor permite que você especifique limites na quantidade de CPU, E/S física e memória que as solicitações de aplicativo de entrada podem usar no pool de recursos. Cada pool de recursos pode conter um ou mais grupos de carga de trabalho. Quando uma sessão é iniciada, o classificador do Resource Governor atribui a sessão a um grupo de carga de trabalho específico e a sessão deve ser executada usando os recursos atribuídos ao grupo de carga de trabalho.

Conceitos do Pool de Recursos

Um pool de recursos ou pool representa os recursos físicos do servidor. Você pode pensar em um 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 se sobrepõe a outros pools, o que permite a reserva mínima de recursos. A outra parte é compartilhada com outros pools, o que dá suporte ao consumo máximo de recursos possível. Os recursos do pool são definidos especificando 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 configurações são a largura de banda média mínima e máxima garantida da CPU 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 previsível de recursos de CPU para várias cargas de trabalho baseadas 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 intensiva de CPU, mas tem consultas de menor prioridade. Ao criar um pool de recursos separado para cada departamento, você pode atribuir um percentual mínimo de CPU de 70 para o pool de recursos vendas e um percentual máximo de CPU de 30 para o pool de recursos de Marketing. Isso 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 da CPU da carga de trabalho de Vendas. Observe que o percentual máximo de CPU é, de forma oportunista, o maior possível. Se houver capacidade de CPU disponível, a carga de trabalho a usará até 100%. O valor máximo só se aplica quando há contenção para recursos de CPU. Neste exemplo, se a carga de trabalho Vendas estiver desativada, a carga de trabalho de Marketing poderá usar 100% da CPU, se necessário.

• CAP_CPU_PERCENT

  Essa configuração é um limite rígido no uso da 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 se estiver disponível, mas não acima do valor de CAP_CPU_PERCENT. Usando o exemplo acima, vamos supor que o departamento de Marketing está sendo cobrado pelo uso de recursos. Eles querem cobrança previsível e não querem pagar mais de 30% da CPU. Isso pode ser feito definindo o CAP_CPU_PERCENT como 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 compartilhado com outros pools de recursos. A memória referenciada aqui é memória de concessão de execução de consulta, não memória do pool de buffers (por exemplo, páginas de dados e índice). Definir um valor mínimo de memória para um pool significa que você está garantindo que a porcentagem de memória especificada estará disponível para quaisquer solicitações que possam ser executadas neste pool de recursos. Esse é um diferencial importante em comparação com MIN_CPU_PERCENT, pois, nesse caso, a memória pode permanecer no pool de recursos especificado mesmo quando o pool não tiver nenhuma solicitação nos grupos de carga de trabalho que pertencem a esse pool. Portanto, é crucial que você tenha muito cuidado ao usar essa configuração, pois essa memória não estará disponível para uso por qualquer outro pool, mesmo quando não houver solicitações ativas. Definir um valor máximo de memória para um pool significa que, quando as solicitações estiverem em execução nesse pool, elas nunca obterão mais do que esse percentual de memória geral.

• AFINIDADE

  Essa configuração permite que você vincule um pool de recursos a um ou mais agendadores ou nós NUMA para melhorar o isolamento dos recursos da CPU. Usando o cenário de Vendas e Marketing acima, vamos supor que o departamento de Vendas precisa de um ambiente mais isolado e deseja 100% de um núcleo de CPU o tempo todo. 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 em vigor, a carga de trabalho de Marketing continua a usar no máximo 30% de um núcleo, enquanto a carga de trabalho de Vendas usa 100% do outro núcleo. No que diz respeito às cargas de trabalho de Vendas e Marketing, elas estão em execução em dois computadores isolados.

• MIN_IOPS_PER_VOLUME e MAX_IOPS_PER_VOLUME

  Essas configurações são as operações de E/S físicas mínimas e máximas por segundo (IOPS) por volume de disco para um pool de recursos. Você pode usar essas configurações para controlar os IOs físicos emitidos para threads de usuário para um determinado pool de recursos. Por exemplo, o departamento de Vendas gera vários relatórios de fim de mês em lotes grandes. As consultas nesses lotes podem gerar IOs que podem potencialmente saturar o volume de disco e impactar 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, que controla o nível de IOs que podem ser emitidos para a carga de trabalho.

Ao configurar a CPU ou a Memória, a soma dos valores MIN em todos os pools não pode exceder 100% dos recursos do servidor. Além disso, ao configurar os valores de CPU ou Memória, MAX e CAP podem ser definidos em qualquer lugar no intervalo entre MIN e 100% 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ída de 100%.

A tabela a seguir ilustra alguns dos conceitos anteriores. A tabela mostra as configurações para o pool interno, o pool padrão e dois pools definidos pelo usuário. As fórmulas a seguir são usadas para calcular o max% efetivo e o %compartilhado.

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

• Soma(X) significa a soma do valor X em todos os pools.

• Total de % compartilhados = 100 – soma (MIN %).

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

• Compartilhado % = Máximo efetivo % - Mínimo %.

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

A parte compartilhada do pool é usada para indicar para onde os recursos disponíveis podem ir se os recursos estiverem disponíveis. No entanto, quando os recursos são consumidos, eles vão para o pool especificado e não são compartilhados. Isso pode melhorar a utilização de recursos nos casos em que não há solicitações em um determinado pool e os recursos configurados para o pool podem ser liberados para outros pools.

Alguns casos extremos de configuração do pool são:

• Todos os pools definem mínimos que somam 100% dos recursos do servidor. Nesse caso, os máximos efetivos são iguais aos mínimos. Isso é equivalente à divisão dos recursos do servidor em partes não sobrepostas, independentemente dos recursos serem consumidos dentro de um determinado pool.

• Todos os grupos não têm mínimo. Todos os pools competem por recursos disponíveis e seus tamanhos finais são baseados no consumo de recursos em cada pool. Outros fatores, como políticas, desempenham um papel na formatação do tamanho final do pool.

O Administrador de Recursos predefini dois pools de recursos, o pool interno e o pool padrão.

Pool interno

O pool interno representa os recursos consumidos pelo próprio SQL Server. Esse pool sempre contém apenas o grupo interno e o pool não é alterável de forma alguma. O consumo de recursos pelo pool interno não é restrito. Todas as cargas de trabalho no pool são consideradas críticas para a função de servidor e o Administrador de Recursos permite que o pool interno pressione outros pools mesmo que isso signifique a violação dos limites definidos para os outros pools.

Pool Padrão

O pool padrão é o primeiro pool de usuários predefinido. Antes de qualquer configuração, o pool padrão contém apenas o grupo padrão. O pool padrão não pode ser criado ou descartado, mas pode ser alterado. O pool padrão pode conter grupos definidos pelo usuário além do grupo padrão.

Pools de RecursosUser-Defined

Os pools de recursos definidos pelo usuário são aqueles que você cria para cargas de trabalho específicas em seu ambiente. O Resource Governor fornece instruções DDL para criar, alterar e remover pools de recursos.

Tarefas do Pool de Recursos

Consulte Também

Administrador de Recursos
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