Gestão de recursos em conjuntos elásticos densos
Aplica-se a:
Banco de Dados SQL do Azure
Os pools elásticos do Banco de Dados SQL do Azure são uma solução econômica para gerenciar muitos bancos de dados com uso variável de recursos. Todos os bancos de dados em um pool elástico compartilham a mesma alocação de recursos, como CPU, memória, threads de trabalho, espaço de armazenamento, , tempdbna suposição de que apenas um subconjunto de bancos de dados no pool usará recursos de computação a qualquer momento. Essa suposição permite que pools elásticos sejam econômicos. Em vez de pagar por todos os recursos que cada banco de dados individual poderia precisar, os clientes pagam por um conjunto muito menor de recursos, compartilhados entre todos os bancos de dados no pool.
Governação de recursos
O compartilhamento de recursos requer que o sistema controle cuidadosamente o uso de recursos para minimizar o efeito de "vizinho barulhento", em que um banco de dados com alto consumo de recursos afeta outros bancos de dados no mesmo pool elástico. O Banco de Dados SQL do Azure atinge essas metas implementando a governança de recursos. Ao mesmo tempo, o sistema deve fornecer recursos suficientes para recursos como alta disponibilidade e recuperação de desastres (HADR), backup e restauração, monitoramento, armazenamento de consultas, ajuste automático, etc. para funcionar de forma fiável.
O principal objetivo do projeto de piscinas elásticas é ser econômico. Por esse motivo, o sistema permite intencionalmente que os clientes criem pools densos , ou seja, pools com o número de bancos de dados próximo ou no máximo permitido, mas com uma alocação moderada de recursos de computação. Pela mesma razão, o sistema não reserva todos os recursos potencialmente necessários para seus processos internos, mas permite o compartilhamento de recursos entre processos internos e cargas de trabalho do usuário.
Essa abordagem permite que os clientes usem pools elásticos densos para obter desempenho adequado e grandes economias de custos. No entanto, se a carga de trabalho em relação a muitos bancos de dados em um pool denso for suficientemente intensa, a contenção de recursos se tornará significativa. A contenção de recursos reduz o desempenho da carga de trabalho do usuário e pode afetar negativamente os processos internos.
Importante
Em pools densos com muitos bancos de dados ativos, pode não ser viável aumentar o número de bancos de dados no pool até os máximos documentados para pools elásticos DTU e vCore .
O número de bancos de dados que podem ser colocados em pools densos sem causar contenção de recursos e problemas de desempenho depende do número de bancos de dados ativos simultaneamente e do consumo de recursos pelas cargas de trabalho do usuário em cada banco de dados. Esse número pode mudar ao longo do tempo à medida que as cargas de trabalho do usuário mudam.
Além disso, se a configuração min vCores por banco de dados ou min DTUs por banco de dados for definida como um valor maior que 0, o número máximo de bancos de dados no pool será implicitamente limitado. Para obter mais informações, consulte Propriedades de banco de dados para bancos de dados vCore agrupados e Propriedades de banco de dados para bancos de dados DTU em pool.
Quando a contenção de recursos ocorre em um pool densamente compactado, os clientes podem escolher uma ou mais das seguintes ações para atenuá-la:
- Ajuste a carga de trabalho de consulta para reduzir o consumo de recursos ou distribua o consumo de recursos por vários bancos de dados ao longo do tempo.
- Reduza a densidade do pool movendo alguns bancos de dados para outro pool ou tornando-os bancos de dados autônomos.
- Aumente verticalmente o conjunto para obter mais recursos.
Para obter sugestões sobre como implementar as duas últimas ações, consulte Recomendações operacionais mais adiante neste artigo. A redução da contenção de recursos beneficia as cargas de trabalho do usuário e os processos internos e permite que o sistema mantenha de forma confiável o nível de serviço esperado.
Monitorização do consumo de recursos
Para evitar a degradação do desempenho devido à contenção de recursos, os clientes que usam pools elásticos densos devem monitorar proativamente o consumo de recursos e tomar medidas oportunas se o aumento da contenção de recursos começar a afetar as cargas de trabalho. O monitoramento contínuo é importante porque o uso de recursos em um pool muda ao longo do tempo, devido a alterações na carga de trabalho do usuário, alterações nos volumes e distribuição de dados, alterações na densidade do pool e alterações no serviço Banco de Dados SQL do Azure.
O Banco de Dados SQL do Azure fornece várias métricas que são relevantes para esse tipo de monitoramento. Exceder o valor médio recomendado para cada métrica indica contenção de recursos no pool e deve ser abordado usando uma das ações mencionadas anteriormente.
Para enviar um alerta quando a utilização de recursos do pool (CPU, E/S de dados, E/S de log, trabalhadores, etc.) exceder um limite, considere a criação de alertas por meio do portal do Azure ou do cmdlet Add-AzMetricAlertRulev2 PowerShell. Ao monitorar pools elásticos, considere também a criação de alertas para bancos de dados individuais no pool, se necessário em seu cenário. Para obter um cenário de exemplo de monitoramento de pools elásticos, consulte Monitorar e gerenciar o desempenho do Banco de Dados SQL do Azure em um aplicativo SaaS multilocatário.
| Nome da métrica | Description | Valor médio recomendado |
|---|---|---|
avg_instance_cpu_percent |
Utilização da CPU do processo SQL associado a um pool elástico, conforme medido pelo sistema operacional subjacente. Disponível na visualização sys.dm_db_resource_stats em todos os bancos de dados e na visualização sys.elastic_pool_resource_stats no master banco de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadasql_instance_cpu_percent, e pode ser exibida no portal do Azure. Esse valor é o mesmo para todos os bancos de dados no mesmo pool elástico. |
Abaixo de 70%. Picos curtos ocasionais de até 90% podem ser aceitáveis. |
max_worker_percent |
Utilização de threads de trabalho. Fornecido para cada banco de dados no pool, bem como para o próprio pool. Há limites diferentes para o número de threads de trabalho no nível do banco de dados e no nível do pool, portanto, o monitoramento dessa métrica em ambos os níveis é recomendado. Disponível na visualização sys.dm_db_resource_stats em todos os bancos de dados e na visualização sys.elastic_pool_resource_stats no master banco de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadaworkers_percent, e pode ser exibida no portal do Azure. |
Abaixo de 80%. Picos de até 100% farão com que as tentativas de conexão e consultas falhem. |
avg_data_io_percent |
Utilização de IOPS para E/S físicas de leitura e gravação. Fornecido para cada banco de dados no pool, bem como para o próprio pool. Há limites diferentes para o número de IOPS no nível do banco de dados e no nível do pool, portanto, o monitoramento dessa métrica em ambos os níveis é recomendado. Disponível na visualização sys.dm_db_resource_stats em todos os bancos de dados e na visualização sys.elastic_pool_resource_stats no master banco de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadaphysical_data_read_percent, e pode ser exibida no portal do Azure. |
Abaixo de 80%. Picos curtos ocasionais de até 100% podem ser aceitáveis. |
avg_log_write_percent |
Utilizações de taxa de transferência para E/S de gravação de log de transações. Fornecido para cada banco de dados no pool, bem como para o próprio pool. Há diferentes limites na taxa de transferência de log no nível do banco de dados e no nível do pool, portanto, o monitoramento dessa métrica em ambos os níveis é recomendado. Disponível na visualização sys.dm_db_resource_stats em todos os bancos de dados e na visualização sys.elastic_pool_resource_stats no master banco de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadalog_write_percent, e pode ser exibida no portal do Azure. Quando essa métrica está próxima de 100%, todas as modificações do banco de dados (instruções INSERT, UPDATE, DELETE, MERGE, SELECT ... INTO, INSERÇÃO EM MASSA, etc.) será mais lento. |
Abaixo de 90%. Picos curtos ocasionais de até 100% podem ser aceitáveis. |
oom_per_second |
A taxa de erros de falta de memória (OOM) em um pool elástico, que é um indicador da pressão da memória. Disponível na vista sys.dm_resource_governor_resource_pools_history_ex. Consulte Exemplos de uma consulta de exemplo para calcular essa métrica. Para obter mais informações, consulte Limites de recursos para pools elásticos usando DTUs ou pools elásticos usando vCores e Solucionar erros de falta de memória com o Banco de Dados SQL do Azure. Se encontrar erros de memória esgotada, veja sys.dm_os_out_of_memory_events. | 0 |
avg_storage_percent |
Espaço de armazenamento total usado pelos dados em todos os bancos de dados dentro de um pool elástico. Não inclui espaço vazio em arquivos de banco de dados. Disponível na vista sys.elastic_pool_resource_stats na master base de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadastorage_percent, e pode ser exibida no portal do Azure. |
Abaixo de 80%. Pode se aproximar de 100% para pools sem crescimento de dados. |
avg_allocated_storage_percent |
Espaço de armazenamento total usado pelos arquivos de banco de dados em armazenamento em todos os bancos de dados dentro de um pool elástico. Inclui espaço vazio em arquivos de banco de dados. Disponível na vista sys.elastic_pool_resource_stats na master base de dados. Essa métrica também é emitida para o Azure Monitor, onde é nomeadaallocated_data_storage_percent, e pode ser exibida no portal do Azure. |
Abaixo de 90%. Pode se aproximar de 100% para pools sem crescimento de dados. |
tempdb_log_used_percent |
Utilização do espaço do log de tempdb transações no banco de dados. Embora os objetos temporários criados em um banco de dados não sejam visíveis em outros bancos de dados no mesmo pool elástico, tempdb é um recurso compartilhado para todos os bancos de dados no mesmo pool. Uma transação órfã ou de execução longa iniciada a tempdb partir de um banco de dados no pool pode consumir uma grande parte do log de transações e causar falhas para consultas em outros bancos de dados no mesmo pool. Derivado de sys.dm_db_log_space_usage e sys.database_files vistas. Essa métrica também é emitida para o Azure Monitor e pode ser exibida no portal do Azure. Consulte Exemplos de uma consulta de exemplo para retornar o valor atual dessa métrica. |
Abaixo de 50%. Picos ocasionais de até 80% são aceitáveis. |
Além dessas métricas, o Banco de Dados SQL do Azure fornece uma exibição que retorna limites reais de governança de recursos, bem como exibições adicionais que retornam estatísticas de utilização de recursos no nível do pool de recursos e no nível do grupo de carga de trabalho.
| View name | Description |
|---|---|
| sys.dm_user_db_resource_governance | Retorna as configurações reais e as configurações de capacidade usadas pelos mecanismos de governança de recursos no banco de dados atual ou no pool elástico. |
| sys.dm_resource_governor_resource_pools | Retorna informações sobre o estado atual do pool de recursos, a configuração atual dos pools de recursos e as estatísticas cumulativas do pool de recursos. |
| sys.dm_resource_governor_workload_groups | Retorna estatísticas de grupo de carga de trabalho cumulativa e a configuração atual do grupo de carga de trabalho. Essa exibição pode ser unida com sys.dm_resource_governor_resource_pools na coluna para obter informações do pool_id pool de recursos. |
| sys.dm_resource_governor_resource_pools_history_ex | Retorna estatísticas de utilização do pool de recursos para o histórico recente, com base no número de instantâneos disponíveis. Cada linha representa um intervalo de tempo. A duração do intervalo é fornecida na duration_ms coluna. As delta_ colunas retornam a alteração em cada estatística durante o intervalo. |
| sys.dm_resource_governor_workload_groups_history_ex | Retorna estatísticas de utilização do grupo de carga de trabalho para o histórico recente, com base no número de instantâneos disponíveis. Cada linha representa um intervalo de tempo. A duração do intervalo é fornecida na duration_ms coluna. As delta_ colunas retornam a alteração em cada estatística durante o intervalo. |
Gorjeta
Para consultar essas e outras exibições de gerenciamento dinâmico usando uma entidade diferente do administrador do servidor, adicione essa entidade à ##MS_ServerStateReader##função de servidor.
Essas exibições podem ser usadas para monitorar a utilização de recursos e solucionar problemas de contenção de recursos quase em tempo real. A carga de trabalho do usuário nas réplicas primárias e secundárias legíveis, incluindo réplicas geográficas, é classificada no pool de recursos e UserPrimaryGroup.DBId[N] no SloSharedPool1 grupo de carga de trabalho, onde N significa o valor de ID do banco de dados.
Além de monitorar a utilização atual de recursos, os clientes que usam pools densos podem manter dados históricos de utilização de recursos em um armazenamento de dados separado. Esses dados podem ser usados na análise preditiva para gerenciar proativamente a utilização de recursos com base em tendências históricas e sazonais.
Recomendações operacionais
Deixe espaço suficiente para recursos. Se ocorrer contenção de recursos e degradação do desempenho, a atenuação pode envolver a remoção de alguns bancos de dados do pool elástico afetado ou a expansão do pool, conforme observado anteriormente. No entanto, essas ações exigem recursos de computação adicionais para serem concluídas. Em particular, para pools Premium e Business Critical, essas ações exigem a transferência de todos os dados para os bancos de dados que estão sendo movidos ou para todos os bancos de dados no pool elástico se o pool for ampliado. A transferência de dados é uma operação de longa duração e que consome muitos recursos. Se o pool já estiver sob alta pressão de recursos, a própria operação de mitigação degradará ainda mais o desempenho. Em casos extremos, pode não ser possível resolver a contenção de recursos por meio da movimentação do banco de dados ou da ampliação do pool porque os recursos necessários não estão disponíveis. Nesse caso, reduzir temporariamente a carga de trabalho de consulta no pool elástico afetado pode ser a única solução.
Os clientes que usam pools densos devem monitorar de perto as tendências de utilização de recursos, conforme descrito anteriormente, e tomar medidas atenuantes enquanto as métricas permanecem dentro dos intervalos recomendados e ainda há recursos suficientes no pool elástico.
A utilização de recursos depende de vários fatores que mudam ao longo do tempo para cada banco de dados e cada pool elástico. Alcançar a relação preço/desempenho ideal em pools densos requer monitoramento e reequilíbrio contínuos, ou seja, mover bancos de dados de pools mais utilizados para pools menos utilizados e criar novos pools conforme necessário para acomodar o aumento da carga de trabalho.
Nota
Para pools elásticos de DTU, a métrica eDTU no nível do pool não é um MAX ou uma SOMA de utilização individual do banco de dados. Deriva da utilização de várias métricas ao nível do conjunto. Os limites de recursos ao nível do conjunto podem ser superiores aos limites ao nível da base de dados individual, pelo que é possível que uma base de dados individual possa atingir um limite de recursos específico (CPU, entrada/saída de dados, entrada/saída de registo, etc.), mesmo quando os relatórios de eDTUs do conjunto indicam que não foi atingido nenhum limite.
Não mova bancos de dados "quentes". Se a contenção de recursos no nível do pool for causada principalmente por um pequeno número de bancos de dados altamente utilizados, pode ser tentador mover esses bancos de dados para um pool menos utilizado ou torná-los bancos de dados autônomos. No entanto, fazer isso enquanto um banco de dados permanece altamente utilizado não é recomendado, porque a operação de movimentação degradará ainda mais o desempenho, tanto para o banco de dados que está sendo movido quanto para todo o pool. Em vez disso, aguarde até que a alta utilização diminua ou mova bancos de dados menos utilizados para aliviar a pressão de recursos no nível do pool. Mas mover bancos de dados com utilização muito baixa não oferece nenhum benefício neste caso, porque não reduz materialmente a utilização de recursos no nível do pool.
Crie novos bancos de dados em um pool de "quarentena". Em cenários em que novos bancos de dados são criados com frequência, como aplicativos que usam o modelo de locatário por banco de dados, há risco de que um novo banco de dados colocado em um pool elástico existente consuma inesperadamente recursos significativos e afete outros bancos de dados e processos internos no pool. Para mitigar esse risco, crie um pool de "quarentena" separado com ampla alocação de recursos. Use esse pool para novos bancos de dados com padrões de consumo de recursos ainda desconhecidos. Depois que um banco de dados permanecer nesse pool por um ciclo de negócios, como uma semana ou um mês, e seu consumo de recursos for conhecido, ele poderá ser movido para um pool com capacidade suficiente para acomodar esse uso adicional de recursos.
Monitore o espaço usado e alocado. Quando o espaço de pool alocado (tamanho total de todos os arquivos de banco de dados em armazenamento para todos os bancos de dados em um pool) atinge o tamanho máximo do pool, erros de falta de espaço podem ocorrer. Se o espaço alocado tende a ser alto e estiver no caminho certo para atingir o tamanho máximo do pool, as opções de mitigação incluem:
- Mover alguns bancos de dados para fora do pool para reduzir o espaço total alocado
- Reduzir arquivos de banco de dados para reduzir o espaço alocado vazio nos arquivos
- Aumente a escala do pool para um objetivo de serviço com um tamanho máximo maior do pool
Se o espaço de pool usado (tamanho total dos dados em todos os bancos de dados em um pool, não incluindo espaço vazio em arquivos) tiver uma tendência alta e estiver no caminho certo para atingir o tamanho máximo do pool, as opções de mitigação incluem:
- Mover alguns bancos de dados para fora do pool para reduzir o espaço total usado
- Mover (arquivar) dados para fora do banco de dados ou excluir dados que não são mais necessários
- Implementar compactação de dados
- Aumente a escala do pool para um objetivo de serviço com um tamanho máximo maior do pool
Evite servidores excessivamente densos. A Base de Dados SQL do Azure suporta até 5000 bases de dados por servidor. Os clientes que usam pools elásticos com milhares de bancos de dados podem considerar colocar vários pools elásticos em um único servidor, com o número total de bancos de dados até o limite suportado. No entanto, servidores com muitos milhares de bancos de dados criam desafios operacionais. As operações que exigem a enumeração de todos os bancos de dados em um servidor, por exemplo, a exibição de bancos de dados no portal, serão mais lentas. Erros operacionais, como modificação incorreta de logins no nível do servidor ou regras de firewall, afetarão um número maior de bancos de dados. A exclusão acidental do servidor exigirá assistência do Suporte da Microsoft para recuperar bancos de dados no servidor excluído e causará uma interrupção prolongada para todos os bancos de dados afetados.
Limite o número de bancos de dados por servidor a um número menor do que o máximo suportado. Em muitos cenários, usar até 1000-2000 bancos de dados por servidor é ideal. Para reduzir a probabilidade de exclusão acidental do servidor, coloque um bloqueio de exclusão no servidor ou em seu grupo de recursos.
Exemplos
Exibir configurações individuais de capacidade do banco de dados
Use o sys.dm_user_db_resource_governance modo de exibição de gerenciamento dinâmico para exibir as configurações reais e as definições de capacidade usadas pela governança de recursos no banco de dados atual ou no pool elástico. Para obter mais informações, consulte sys.dm_user_db_resource_governance.
Execute essa consulta em qualquer banco de dados em um pool elástico. Todos os bancos de dados no pool têm as mesmas configurações de governança de recursos.
SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();
Monitorando o consumo geral de recursos do pool elástico
Use a exibição de catálogo do sys.elastic_pool_resource_stats sistema para monitorar o consumo de recursos de todo o pool. Para obter mais informações, consulte sys.elastic_pool_resource_stats.
Esta consulta de exemplo para exibir os últimos 10 minutos deve ser executada master no banco de dados do servidor SQL lógico do Azure que contém o pool elástico desejado.
SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME())
AND rs.elastic_pool_name = '<elastic pool name>';
Monitorando o consumo individual de recursos do banco de dados
Use o modo de exibição de gerenciamento dinâmico para monitorar o sys.dm_db_resource_stats consumo de recursos de bancos de dados individuais. Para obter mais informações, consulte sys.dm_db_resource_stats. Existe uma linha para cada 15 segundos, mesmo que não haja atividade. Os dados históricos são mantidos por aproximadamente uma hora.
Esta consulta de exemplo para exibir os últimos 10 minutos de dados deve ser executada no banco de dados desejado.
SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());
Para um tempo de retenção mais longo com menos frequência, considere a seguinte consulta no , executado no sys.resource_statsmaster banco de dados do servidor lógico SQL do Azure. Para obter mais informações, consulte sys.resource_stats (Banco de Dados SQL do Azure). Existe uma linha a cada cinco minutos e os dados históricos são mantidos por duas semanas.
SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;
Monitorando a utilização da memória
Essa consulta calcula a métrica de cada pool de recursos para o oom_per_second histórico recente, com base no número de instantâneos disponíveis. Esta consulta de exemplo ajuda a identificar o número médio recente de alocações de memória com falha no pool. Essa consulta pode ser executada em qualquer banco de dados em um pool elástico.
SELECT pool_id,
name AS resource_pool_name,
IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;
Monitorando a utilização do tempdb espaço de log
Essa consulta retorna o valor atual da tempdb_log_used_percent métrica, mostrando a utilização relativa do tempdb log de transações em relação ao seu tamanho máximo permitido. Essa consulta pode ser executada em qualquer banco de dados em um pool elástico.
SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
FROM tempdb.sys.database_files
WHERE type_desc = N'LOG'
) AS df
;
Próximos passos
- Para obter uma introdução aos pools elásticos, consulte Pools elásticos ajudam a gerenciar e dimensionar vários bancos de dados no Banco de Dados SQL do Azure.
- Para obter informações sobre como ajustar cargas de trabalho de consulta para reduzir a utilização de recursos, consulte Monitoramento e ajuste e Monitoramento e ajuste de desempenho.