Em cenários com alto volume de conexões, o modelo padrão do MySQL (uma thread por sessão) gera agendamento excessivo de threads e falhas frequentes de cache, o que reduz drasticamente o throughput. O thread pool do PolarDB substitui esse modelo por um conjunto fixo de grupos de threads que atendem a várias sessões simultaneamente, garantindo desempenho estável mesmo sob cargas com muitas conexões e alta concorrência.
Como funciona
O thread pool do PolarDB utiliza 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, evitando a saturação da CPU. Dentro de cada grupo de threads, uma fila de alta prioridade e outra de baixa prioridade permitem que o pool atenda a comandos administrativos e transações em andamento antes de processar instruções complexas ou enfileiradas.
Como resultado:
Comandos administrativos (novas conexões, monitoramento, manutenção) são executados prontamente, mesmo durante picos de carga.
Instruções complexas ou enfileiradas têm sua taxa limitada para evitar o esgotamento dos recursos do sistema.
Transações em andamento recebem tratamento prioritário, reduzindo a contenção de recursos.
Configure o thread pool
Modifique os parâmetros do thread pool no console do PolarDB. Para obter instruções, consulte Definir parâmetros de cluster e nó.
Todos os parâmetros de cluster no console do PolarDB possuem o prefixo loose_ para garantir compatibilidade com arquivos de configuração do MySQL. Selecione os parâmetros com o prefixo loose_ ao modificá-los no console.
Configurações gerais
| Parâmetro | Descrição | Padrão |
|---|---|---|
loose_thread_pool_enabled | Ative ou desative o thread pool. Valores válidos: ON, OFF. Não é necessário reiniciar o cluster. O valor padrão varia conforme a versão: MySQL 5.6 tem como padrão OFF; MySQL 5.7, 8.0.1 e 8.0.2 têm como padrão ON. | Dependente da versão |
loose_thread_pool_size | Número de grupos de threads no pool. Intervalo válido: DBNodeClassCPU a DBNodeClassCPU × 10, onde DBNodeClassCPU representa a quantidade de núcleos de CPU no nó primário. Padrão: DBNodeClassCPU × 2 (MySQL 5.7: DBNodeClassCPU). Consulte os exemplos abaixo. | DBNodeClassCPU × 2 |
loose_thread_pool_oversubscribe | Limite de threads ativas (threads executando instruções SQL) por grupo de threads. Intervalo válido: 1–1.000. | 20 |
loose_thread_pool_stall_limit | Tempo em milissegundos antes que o pool seja considerado travado. Quando isso ocorre, o sistema cria uma nova thread para atender às instruções recebidas. Intervalo válido: 1–18.446.744.073.709.551.615. Padrão no MySQL 5.6: 30 ms. | 10 ms |
loose_thread_pool_idle_timeout | Tempo em segundos antes que uma thread ociosa seja liberada. Intervalo válido: 0–31.536.000. Aplicável ao MySQL 5.6 e 5.7. | 60 s |
Dimensionamento de loose_thread_pool_size
Comece com o valor padrão (DBNodeClassCPU × 2) e monitore o throughput. Para cargas de trabalho intensivas em InnoDB, valores próximos à contagem física de núcleos de CPU costumam apresentar bom desempenho; já para cargas com muitas transações curtas, valores mais altos podem ser benéficos. Evite definir este valor acima de DBNodeClassCPU × 10.
Exemplos:
|
Tipo de cluster |
Versão do mecanismo |
Nó primário |
Intervalo válido |
Padrão |
|
Cluster Edition |
MySQL 8.0.1 |
4 núcleos |
4–40 |
8 |
|
Multi-master Cluster (Database/Table) |
MySQL 8.0.1 |
2 × 4 núcleos |
8–80 |
16 |
|
Cluster Edition |
MySQL 5.7 |
4 núcleos |
4–40 |
4 |
Tratamento de prioridades
|
Parâmetro |
Descrição |
Padrão |
|
|
Defina quais instruções entram na fila de alta prioridade. Valores válidos: transactions — instruções dentro de uma transação ativa são enfileiradas com alta prioridade pelo número de execuções especificado em |
transactions |
|
|
Quantidade de execuções de alta prioridade concedidas a uma única transação antes que ela seja movida para a fila de menor prioridade. Intervalo válido: 0–4.294.967.295. Aplicável ao MySQL 5.6 e 5.7. |
4.294.967.295 |
|
|
Lista separada por vírgulas de contas de banco de dados cujas solicitações são sempre colocadas na fila de alta prioridade. Exemplo: |
— |
Configurações de bypass
|
Parâmetro |
Descrição |
Padrão |
|
|
Lista separada por vírgulas de endereços IP de clientes que ignoram as restrições do thread pool. Utilize esta opção para manter as conexões administrativas disponíveis quando o thread pool estiver saturado. Exemplo: |
— |
|
|
Controla se os IPs de clientes proxy são verificados em relação a |
ON |
Gerenciamento de threads DDL
|
Parâmetro |
Descrição |
Padrão |
|
|
Tempo limite em segundos para threads DDL. Após esse período, a thread DDL é marcada como expirada e o sistema cria uma nova thread para lidar com solicitações pendentes. Intervalo válido: 0–864.000. Aplicável ao MySQL 8.0.1 revisão ≥ 8.0.1.1.19. |
600 s |
|
|
Quando ativado, marca imediatamente uma thread DDL como expirada se o thread pool estiver sob alta carga e a fila de menor prioridade acumulada, fazendo com que o sistema crie uma nova thread. Ative esta opção para cargas de trabalho com operações DDL em lote frequentes. Valores válidos: ON, OFF. Aplicável ao MySQL 8.0.1 revisão ≥ 8.0.1.1.19. |
OFF |
Verificar o status do thread pool
Execute a consulta a seguir para inspecionar o estado atual de cada grupo de threads:
SELECT * FROM information_schema.THREAD_POOL_STATUS;Exemplo de saída:
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)Descrição dos campos:
|
Campo |
Descrição |
|
|
ID do grupo de threads |
|
|
Total de threads no grupo |
|
|
Threads executando instruções SQL no momento |
|
|
Threads aguardando E/S de disco ou commits de transação |
|
|
Conexões persistentes da classe DUMP |
|
|
Threads marcadas como expiradas |
|
|
Conexões de usuário estabelecidas no grupo |
|
|
Solicitações aguardando na fila de menor prioridade |
|
|
Solicitações aguardando na fila de alta prioridade |
Testes Sysbench
As figuras a seguir comparam o throughput com e sem o thread pool em quatro cargas de trabalho de Processamento de Transações Online (OLTP). Os resultados demonstram ganhos significativos de desempenho em cenários de alta concorrência.
Figura 1. Teste OLTP para atualizações sem índice 
Figura 2. Teste OLTP somente escrita 
Figura 3. Teste OLTP somente leitura 
Figura 4. Teste OLTP leitura/escrita 