Para obter o melhor desempenho do PolarDB for MySQL, o PolarDB oferece o recurso de pool de threads, que separa threads de sessões. É possível manter muitas sessões abertas ao mesmo tempo, enquanto apenas um número pequeno de threads executa as tarefas das sessões ativas.
Benefícios
Por padrão, o MySQL usa o modo exclusivo de sessão, no qual cada sessão cria uma thread dedicada. Quando há muitas sessões, a forte competição por recursos degrada o desempenho. O agendamento intenso de threads do sistema e as falhas de cache também provocam uma queda acentuada no desempenho.
O pool de threads do PolarDB implementa mecanismos de prioridade e controle de concorrência para diferentes tipos de operações SQL. Ele mantém o número de conexões próximo ao nível ideal, o que permite que os bancos de dados PolarDB mantenham alto desempenho mesmo com alto número de conexões e alta concorrência. O pool de threads oferece os seguintes benefícios:
Quando muitas threads são executadas simultaneamente, o pool de threads mantém automaticamente o número de threads concorrentes dentro de uma faixa razoável, o que evita o agendamento excessivo de threads e as falhas de cache.
Quando muitas transações são executadas simultaneamente, o pool de threads atribui instruções e transações a diferentes prioridades e controla a concorrência de instruções e transações separadamente, o que reduz a competição por recursos.
O pool de threads concede prioridade mais alta às instruções SQL de gerenciamento, para que essas instruções sejam executadas primeiro. Assim, novas conexões, operações de gerenciamento e monitoramento permanecem estáveis mesmo quando a carga do sistema está alta.
O pool de threads concede prioridade relativamente mais baixa às instruções SQL de consultas complexas e limita a concorrência máxima dessas instruções. Isso evita que muitas instruções SQL complexas esgotem os recursos do sistema e tornem todo o serviço de banco de dados indisponível.
Usar o pool de threads
O recurso de pool de threads inclui os seguintes parâmetros, que podem ser modificados no console. Para obter mais informações, consulte Definir parâmetros do cluster e parâmetros do nó.
Os parâmetros do cluster no PolarDB console usam o prefixo de compatibilidade do arquivo de configuração do MySQL loose_. Para modificar parâmetros no PolarDB console, modifique os parâmetros que têm o prefixo loose_.
Parâmetro | Descrição |
loose_thread_pool_enabled | Especifica se o pool de threads deve ser habilitado. Valores válidos:
Nota
|
loose_thread_pool_size | O número de grupos de threads no pool de threads. A faixa de valores depende do número de núcleos de CPU nas especificações do nó principal do cluster. Faixa de valores: DBNodeClassCPU~DBNodeClassCPU10. Valor padrão: DBNodeClassCPU2. Nota
Exemplos:
|
loose_thread_pool_high_prio_mode | O modo de fila de alta prioridade do pool de threads. Valores válidos:
Nota Aplica-se a:
|
loose_thread_pool_high_prio_tickets | O número de tickets concedidos por vez para a fila de alta prioridade. Faixa de valores: 0~4294967295. Valor padrão: 4294967295. Nota Aplica-se a:
|
loose_thread_pool_idle_timeout | O limiar de tempo para liberar threads ociosas no pool de threads. Uma thread ociosa que não atendeu nenhuma solicitação além desse limiar é liberada. Faixa de valores: 0~31536000. Valor padrão: 60. Unidade: segundos. Nota Aplica-se a:
|
loose_thread_pool_oversubscribe | O número de threads ativas permitidas em cada grupo de threads. Uma thread ativa é uma thread que está executando uma instrução SQL. Faixa de valores: 1~1000. Valor padrão: 20. |
loose_thread_pool_stall_limit | O limiar de tempo usado para determinar se o pool de threads entrou em estado de estagnação. Quando o pool de threads entra em estado de estagnação, o sistema cria novas threads para atender às instruções SQL. Faixa de valores: 1~18446744073709551615. Valor padrão: 10. Unidade: milissegundos. Nota O MySQL 5.6 tem como valor padrão 30 milissegundos. |
loose_bypass_thread_pool_ips | Configura os endereços IP de cliente que não são restringidos pelo pool de threads. Mesmo quando o pool de threads está cheio, é possível executar instruções SQL para realizar operações de gerenciamento. Exemplo de configuração: Nota Aplica-se a: MySQL 8.0.1 8.0.1 com revisão 8.0.1.1.19 ou posterior. |
loose_bypass_thread_pool_check_ignore_proxy | Especifica se os endereços IP de clientes que se conectam via Proxy devem ser ignorados quando os endereços IP de cliente são detectados por meio de
Nota Aplica-se a: MySQL 8.0.1 com revisão 8.0.1.1.19 ou posterior. |
loose_thread_pool_high_priority_users | Configura contas de banco de dados de alta prioridade. Após a configuração, as solicitações dessas contas são colocadas na fila de alta prioridade do pool de threads e processadas primeiro. Exemplo de configuração: Nota
|
loose_thread_pool_mark_ddl_thread_timeout_sec | Configura o limiar de tempo limite do pool de threads para instruções DDL. Quando esse limiar é ultrapassado, a DDL é marcada como expirada e o sistema cria novas threads para processar as solicitações. Faixa de valores: 0~864000. Valor padrão: 600. Unidade: segundos. Nota Aplica-se a: MySQL 8.0.1 com revisão 8.0.1.1.19 ou posterior. |
loose_thread_pool_mark_ddl_thread_timeout_immediately | Especifica se a DDL deve ser imediatamente marcada como expirada quando o pool de threads está sob alta carga e a fila de baixa prioridade está acumulada. O sistema então cria novas threads para processar as solicitações. Esse parâmetro é adequado para cargas de trabalho que exigem operações DDL em lote frequentes. Valores válidos:
Nota Aplica-se a: MySQL 8.0.1 com revisão 8.0.1.1.19 ou posterior. |
Consultar o status do pool de threads
Execute o seguinte comando para consultar o status do pool de threads:
select * from information_schema.THREAD_POOL_STATUS;
O seguinte exemplo de saída é retornado:
mysql> select * from information_schema.THREAD_POOL_STATUS;
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
| ID | THREAD_COUNT | ACTIVE_THREAD_COUNT | WAITING_THREAD_COUNT | DUMP_THREAD_COUNT | SLOW_THREAD_TIMEOUT_COUNT | CONNECTION_COUNT | LOW_QUEUE_COUNT | HIGH_QUEUE_COUNT |
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
| 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 3 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 4 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 5 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 6 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 7 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 8 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 9 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 10 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 11 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 12 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 13 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 14 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 15 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 16 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 17 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 18 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 19 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 20 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 21 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 22 | 2 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 23 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 24 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 25 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 26 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 27 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 28 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 29 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 30 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
| 31 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 32 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 33 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
| 34 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 35 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 36 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 37 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 38 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 39 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 40 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 41 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 42 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 43 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 44 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 45 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 46 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 47 | 3 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 48 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 49 | 3 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 50 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 51 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 52 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 53 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 54 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 55 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 56 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 57 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 58 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 59 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 60 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 61 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 62 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 63 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
64 rows in set (0.00 sec)
A tabela a seguir descreve os parâmetros.
|
Parâmetro |
Descrição |
|
ID |
O ID do pool de threads. |
|
THREAD_COUNT |
O número de threads no pool de threads. |
|
ACTIVE_THREAD_COUNT |
O número de threads ativas no pool de threads. |
|
WAITING_THREAD_COUNT |
O número de threads no pool de threads que estão aguardando E/S de disco ou confirmação de transação. |
|
DUMP_THREAD_COUNT |
O número de conexões persistentes do tipo DUMP no pool de threads. |
|
SLOW_THREAD_TIMEOUT_COUNT |
O número de threads no pool de threads marcadas como expiradas. |
|
CONNECTION_COUNT |
O número de conexões de usuário estabelecidas no pool de threads. |
|
LOW_QUEUE_COUNT |
O número de solicitações aguardando na fila de baixa prioridade do pool de threads. |
|
HIGH_QUEUE_COUNT |
O número de solicitações aguardando na fila de alta prioridade do pool de threads. |
Testes Sysbench
As figuras a seguir comparam o desempenho com o pool de threads habilitado e desabilitado. Os resultados dos testes mostram que o pool de threads oferece benefícios claros de desempenho sob alta concorrência.
Figura 1. Teste de atualização sem índice OLTP 
Figura 2. Teste apenas de gravação OLTP 
Figura 3. Teste apenas de leitura OLTP 
Figura 4. Teste de leitura/gravação OLTP 
Solucionar problemas de pool de threads cheio
Se o banco de dados apresentar tempos limite de conexão ou solicitações enfileiradas, verifique se o pool de threads está cheio.
Faça login no console do PolarDB e acesse a página de detalhes do cluster de destino.
Escolha .
Compare
thread_pool_running_threads(o número atual de threads em execução) comtp_thread_count(a capacidade total de threads do pool de threads). Sethread_pool_running_threadspermanecer próximo detp_thread_count, o pool de threads está cheio.Verifique as métricas
tp_low_queue_countetp_high_queue_count. Uma acumulação em qualquer uma das filas indica que as solicitações estão enfileiradas e que o pool de threads está cheio.