Melhores práticas de gerenciamento de recursos
Essa prática demonstra como usar o GaussDB(DWS) para gerenciamento de recursos, ajudando as empresas a eliminar gargalos no desempenho de consultas simultâneas. Os trabalhos de SQL podem ser executados sem problemas sem afetar uns aos outros e consumir menos recursos do que antes.
Antes da preparação do experimento, se você não tiver conhecimento sobre gerenciamento de recursos, é aconselhável ler Visão geral da página de gerenciamento de recursos.
Essa prática leva cerca de 60 minutos. O procedimento é os seguintes:
- Passo 1: criar um cluster
- Passo 2: conectar-se a um cluster e importar dados
- Passo 3: criar um pool de recursos
- Passo 4: verificar regras de exceção
Cenários
Quando vários usuários de banco de dados executam trabalhos SQL no GaussDB(DWS) ao mesmo tempo, as seguintes situações podem ocorrer:
- Algumas instruções SQL complexas ocupam recursos de cluster por um longo tempo, afetando o desempenho de outras consultas. Por exemplo, um grupo de usuários do banco de dados envia continuamente consultas complexas e demoradas, e outro grupo de usuários frequentemente envia consultas curtas. Nesse caso, as consultas curtas podem ter que esperar no pool de recursos para que as consultas demoradas sejam concluídas.
- Algumas instruções SQL ocupam muita memória ou espaço em disco devido a distorção de dados ou planos de execução não otimizados. Como resultado, as instruções que não se aplicam a erros de relatório de memória ou o cluster muda para o modo somente leitura.
Para aumentar a taxa de transferência do sistema e melhorar o desempenho de SQL, você pode usar o gerenciamento de carga de trabalho do GaussDB(DWS). Por exemplo, crie um pool de recursos para usuários que enviam tarefas de consulta complexas com frequência e aloque mais recursos a esse pool de recursos. Os trabalhos complexos enviados por esses usuários podem usar somente os recursos desse pool de recursos. Crie outro pool de recursos que ocupe menos recursos e adicione usuários que enviam consultas curtas a esse pool de recursos. Desta forma, os dois tipos de trabalhos podem ser executados sem problemas ao mesmo tempo.
Por exemplo, um banco processa serviços de processamento de transações on-line (OLTP) e processamento analítico on-line (OLAP). A prioridade do serviço de OLAP é menor que a do serviço de OLTP. Um grande número de consultas SQL complexas simultâneas pode causar contenção de recursos do servidor, enquanto um grande número de consultas SQL simples simultâneas podem ser rapidamente processadas sem serem colocadas em fila. Os recursos devem ser adequadamente alocados e gerenciados para garantir que os serviços de OLAP e OLTP possam funcionar sem problemas.
Os serviços OLAP são frequentemente complexos e não exigem alta prioridade ou resposta em tempo real. Os serviços de OLAP e OLTP são operados por usuários diferentes. Por exemplo, o usuário do banco de dados budget_config_user é usado para serviços de transação principal e o usuário report_user do banco de dados é usado para serviços de relatório. Os usuários estão sob gerenciamento independente de CPU e simultaneidade para melhorar a estabilidade do banco de dados.
Com base na pesquisa de carga de trabalho, monitoramento de rotina e teste e verificação de serviços de OLAP, descobriu-se que menos de 50 consultas SQL simultâneas não causam contenção de recursos do servidor ou resposta lenta do sistema de serviço. Os usuários de OLAP podem usar 20% dos recursos da CPU.
Com base na pesquisa de carga de trabalho, monitoramento de rotina e teste e verificação de serviços de OLTP, verifica-se que menos de 100 consultas SQL simultâneas não exercem pressão contínua sobre o sistema. Os usuários de OLTP podem usar 60% dos recursos da CPU.
- Configuração de recursos para usuários de OLAP (correspondente a pool_1): CPU = 20%, memória = 20%, armazenamento = 1.024.000 MB, simultaneidade = 20.
- Configuração de recursos para usuários de OLTP (correspondente a pool_2): CPU = 60%, memória = 60%, armazenamento = 1.024.000 MB, simultaneidade = 200.
Defina a memória máxima que pode ser usada por uma única instrução. Um erro será relatado se o uso de memória exceder o valor.
Em Exception Rule, defina Blocking Time como 1200s e Execution Time como 1800s. Um trabalho de consulta será encerrado após ser executado por mais de 1800 segundos.
Passo 2: conectar-se a um cluster e importar dados
- Para obter detalhes, consulte Usar o cliente de CLI gsql para conectar-se a um cluster.
- Importar dados de amostra. Para obter detalhes , consulte Importação de dados do TPC-H.
- Execute as instruções a seguir para criar o usuário de OLTP budget_config_user e o usuário de OLAP report_user.
1 2
CREATE USER budget_config_user PASSWORD 'password'; CREATE USER report_user PASSWORD 'password';
- Para fins de teste, conceda todas as permissões em todas as tabelas no esquema tpch para ambos os usuários.
1
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA tpch to budget_config_user,report_user;
- Verifique a alocação de recursos dos dois usuários.
1
SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO where username in ('budget_config_user' , 'report_user');
Passo 3: criar um pool de recursos
- Faça logon no console de gerenciamento GaussDB(DWS), clique em um nome de cluster na lista de clusters. A página Resource Management Configurations é exibida.
- Clique em Add Resource Pool para criar um pool de recursos. Crie o pool de recursos de relatório pool_1 e o pool de recursos de transação pool_2 referindo-se a Cenários.
- Modifique as regras de exceção.
- Clique em pool_1 criado.
- Na áreaException Rule, defina Blocking Time como 1200s e Execution Time como 1800s.
- Clique em Save.
- Repita as etapas anteriores para configurar pool_2.
- Vincule usuários.
- Clique em pool_1 à esquerda.
- Clique em Add à direita de User Association.
- Selecione report_user e clique em OK.
- Repita as etapas anteriores para adicionar budget_config_user a pool_2.
Passo 4: verificar regras de exceção
- Efetue logon no banco de dados como usuário report_user.
- Execute o seguinte comando para verificar o pool de recursos ao qual pertence o usuário report_user:
1
SELECT usename,respool FROM pg_user WHERE usename = 'report_user';
O resultado da consulta mostra que o pool de recursos ao qual o usuário report_user pertence é pool_1.
- Verifique a regra de exceção vinculada ao pool de recursos pool_1.
1
SELECT respool_name,mem_percent,active_statements,except_rule FROM pg_resource_pool WHERE respool_name='pool_1';
Confirma-se que a regra de exceção rule_1 está vinculada a pool_1.
- Exiba o tipo de regra e o limite da regra de exceção para o usuário atual.
1
SELECT * FROM pg_except_rule WHERE name = 'rule_1';
O retorno mostra que a regra_1 tem 1200 segundos de tempo de bloco e 1800 segundos de duração de execução.
- PG_EXCEPT_RULE registra informações sobre regras de exceção e é suportado apenas no cluster 8.2.0 ou posterior.
- A relação entre parâmetros na mesma regra de exceção é AND.
- Quando o tempo de bloqueio de uma tarefa excede 1200s e a duração da execução excede 1800s, uma mensagem de erro é exibida, indicando que a regra de exceção é acionada e a tarefa é cancelada.
Se as informações de erro semelhantes a "ERROR: canceling statement due to workload manager exception." forem exibidas durante a execução do trabalho, o trabalho será encerrado porque excede o limite da regra de exceção. Se as regras não precisarem ser modificadas, você precisa otimizar as declarações de serviço para reduzir o tempo de execução.
Para obter detalhes sobre regras de exceção, consulte a seção Regras de exceção.