Melhorar MySQL 8.0 no Fedora 44: tuning para alta carga

Otimizar MySQL 8.0 no Fedora 44 significa ajustar parâmetros de memória, conexões e I/O do InnoDB para que o banco suporte picos de tráfego sem travar nem esgotar RAM. Para fazer esse tuning essencial, siga estes passos:

1. Verifique a RAM total disponível e defina o innodb_buffer_pool_size entre 60% e 70% dela
2. Ajuste max_connections e thread_cache_size conforme o número real de conexões simultâneas
3. Configure innodb_redo_log_capacity e innodb_flush_log_at_trx_commit para equilibrar durabilidade e performance
4. Habilite o slow query log e revise consultas sem índice
5. Reinicie o serviço mysqld e monitore com SHOW ENGINE INNODB STATUS
6. Ajuste o firewalld para liberar a porta 3306 apenas para hosts confiáveis

Pré-requisitos

• Fedora 44 com MySQL 8.0 instalado via dnf e serviço mysqld ativo
• Acesso root ou sudo ao servidor
• Pelo menos 8 GB de RAM dedicados ao MySQL (o exemplo usa innodb_buffer_pool_size = 4G, que requer memória adicional para o sistema operacional e outros processos)
• Backup recente do banco antes de qualquer alteração estrutural
• Acesso ao arquivo de configuração, geralmente em /etc/my.cnf.d/ ou /etc/my.cnf

Ajustando memória e buffer pool do InnoDB

O ponto de maior impacto no desempenho sob carga é o dimensionamento correto do buffer pool do InnoDB. Esse buffer guarda páginas de dados e índices em memória, evitando leituras em disco a cada consulta. No Fedora 44, o arquivo de configuração principal normalmente fica em /etc/my.cnf.d/mysql-server.cnf.

Edite o arquivo e adicione ou ajuste as diretivas abaixo:

[mysqld]
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4
innodb_redo_log_capacity = 1G
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT

O innodb_buffer_pool_instances divide o buffer pool em partes menores para reduzir contenção em ambientes com muitas threads concorrentes. Use um valor entre 4 e 8 em servidores com buffer pool acima de 1 GB. Já o innodb_flush_method = O_DIRECT evita dupla cópia de dados entre o cache do sistema operacional e o buffer pool do MySQL, reduzindo overhead de I/O.

O parâmetro innodb_redo_log_capacity substitui o depreciado innodb_log_file_size a partir do MySQL 8.0.30 e é a forma correta de dimensionar o redo log no MySQL 8.0. Diferentemente do parâmetro antigo, ele pode ser alterado dinamicamente via SET GLOBAL innodb_redo_log_capacity sem necessidade de reinício do serviço.

Após salvar, reinicie o serviço:

sudo systemctl restart mysqld

Para aprofundar o comportamento interno do buffer pool do InnoDB, consulte Manual do InnoDB: tuning de buffer pool e I/O no MySQL 8.0, que detalha o funcionamento interno dessa engine.

Controlando conexões e threads sob carga

Em cenários de alta carga, o número de conexões simultâneas é um dos primeiros limites a serem atingidos. O MySQL 8.0 usa uma thread por conexão por padrão, e isso pode consumir memória rapidamente se não for controlado.

Ajuste as variáveis de conexão no mesmo arquivo de configuração:

[mysqld]
max_connections = 300
thread_cache_size = 50
table_open_cache = 4000
table_open_cache_instances = 8

O thread_cache_size reaproveita threads encerradas em vez de criar novas a cada conexão, reduzindo overhead de CPU em picos de requisições curtas. Se sua aplicação ou driver implementa pool de conexões (como conexões persistentes em PHP-FPM ou bibliotecas de pool em Node.js), o valor de max_connections pode ficar mais baixo; se são conexões diretas e voláteis, aumente com cautela. O consumo de memória por conexão não tem um valor fixo: o mínimo é thread_stack (1 MB por padrão em 64 bits) somado aos buffers por sessão alocados conforme as operações, como sort_buffer_size, join_buffer_size e tabelas temporárias, podendo exceder vários MB por conexão em queries complexas. Dimensione max_connections com base em medições reais de carga e mantenha margem para o sistema operacional.

Para confirmar se o limite está sendo atingido, consulte o status global incluindo o pico histórico de conexões e erros acumulados:

mysql -u root -p -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_connected','Max_used_connections','Connection_errors_max_connections');"

+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| Connection_errors_max_connections| 0     |
| Max_used_connections             | 198   |
| Threads_connected                | 142   |
+----------------------------------+-------+

Otimizando I/O de disco e logs de transação

O desempenho de escrita do MySQL depende diretamente de como o redo log e o flush em disco são configurados. Em cargas de escrita intensa, capacidade de redo log insuficiente força checkpoints frequentes, aumentando a latência de commits. No MySQL 8.0 (a partir da versão 8.0.30), o parâmetro correto para dimensionar o redo log é innodb_redo_log_capacity; o antigo innodb_log_file_size foi depreciado e gera warnings no log de erros se utilizado.

Além do já ajustado innodb_redo_log_capacity, vale configurar o comportamento de I/O:

[mysqld]
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

Esses valores de innodb_io_capacity devem refletir o tipo de armazenamento do servidor. Em discos NVMe, valores entre 2000 e 4000 são um ponto de partida para testes; em HDD tradicional, mantenha próximo do padrão (200) para não saturar o disco com operações de flush. Se o servidor roda em um servidor VPS com armazenamento SSD compartilhado, meça as IOPS sustentadas reais do ambiente e ajuste incrementalmente, observando o uso de I/O com iostat antes de subir esse valor.

Para quem já passou por um pico de carga recente e precisa de um diagnóstico mais orientado a métricas históricas, vale comparar com a abordagem de Otimizar MySQL no Debian 13 após pico de carga com Prometheus, que usa monitoramento contínuo para calibrar essas mesmas variáveis.

Monitorando e validando o tuning aplicado

Depois de aplicar as mudanças, é essencial medir se elas realmente ajudaram. Para verificar a taxa de acerto do buffer pool, use um dos comandos abaixo:

mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G" | grep "Buffer pool hit rate"

Ou, para uma métrica acumulada mais confiável, consulte os contadores do status global:

mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"

O valor de Buffer pool hit rate no SHOW ENGINE INNODB STATUS aparece no formato X / 1000; o alvo é ≥ 990/1000. Se estiver abaixo disso e houver RAM livre no servidor, aumentar o buffer pool tende a reduzir leituras em disco e melhorar a latência. Para uma análise automatizada de todos os parâmetros de configuração, a ferramenta mysqltuner inspeciona variáveis e status do servidor e sugere ajustes baseados em métricas reais de uso — útil para validar o tuning após um período de carga real. Também habilite o slow_query_log para capturar consultas acima de 1 segundo:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1

Crie o diretório de log se necessário, ajuste permissões e restaure o contexto SELinux para que o mysqld possa escrever no caminho em Fedora com SELinux enforcing:

sudo mkdir -p /var/log/mysql
sudo chown mysql:mysql /var/log/mysql
sudo restorecon -Rv /var/log/mysql
sudo systemctl restart mysqld

Revise o log periodicamente com mysqldumpslow para identificar as queries que mais pesam sob carga.

Problemas comuns e como resolver

Sintoma: MySQL trava ou fica lento sob pico de acessos

Causa: buffer pool subdimensionado forçando leituras constantes em disco, ou max_connections esgotado.
Solução: aumente innodb_buffer_pool_size dentro do limite de RAM disponível e verifique Threads_connected e Max_used_connections comparados a max_connections. Se estiver no limite, revise se a aplicação está fechando conexões corretamente.

Sintoma: Erro "Too many connections"

Causa: max_connections atingido, geralmente por conexões não liberadas pela aplicação.
Solução: aumente max_connections temporariamente via SET GLOBAL max_connections = 400; para aliviar o problema imediato, mas investigue o pool de conexões da aplicação e persista o novo valor no my.cnf.

Sintoma: Alto uso de CPU mesmo com buffer pool ajustado

Causa: queries sem índice adequado ou table scans frequentes.
Solução: ative o slow_query_log, rode EXPLAIN nas consultas mais executadas e crie índices nas colunas usadas em WHERE e JOIN. Reduzir table scans costuma ter mais impacto que qualquer ajuste de memória.

Perguntas frequentes

Qual o valor ideal de innodb_buffer_pool_size?

Em um servidor dedicado ao MySQL, recomenda-se destinar de 60% a 70% da RAM total disponível ao innodb_buffer_pool_size. Em um VPS com 8 GB de RAM, por exemplo, começar com valores conservadores em torno de 4 GB a 5 GB reserva memória para o sistema operacional e outros serviços. Monitore o Innodb_buffer_pool_wait_free após o ajuste; valores crescentes indicam que o pool está pequeno ou que o flush de páginas sujas não acompanha a carga.

Por que o MySQL 8.0 consome tanta CPU em alta carga?

O alto consumo de CPU geralmente vem de consultas sem índice adequado, excesso de conexões abertas simultaneamente ou threads de I/O mal dimensionadas no InnoDB. Rodar EXPLAIN nas queries mais frequentes e revisar o slow_query_log ajuda a identificar o gargalo real antes de qualquer tuning de CPU. A ferramenta mysqltuner também pode apontar variáveis de configuração que contribuem para o consumo excessivo de CPU.

Como saber se o innodb_buffer_pool_size está bem dimensionado?

Execute SHOW ENGINE INNODB STATUS e observe a linha Buffer pool hit rate, que aparece no formato X / 1000; o alvo é ≥ 990/1000. Para uma métrica acumulada, compare Innodb_buffer_pool_reads com Innodb_buffer_pool_read_requests via SHOW GLOBAL STATUS. Se a taxa estiver baixa e houver RAM livre no servidor, aumentar o buffer pool tende a reduzir leituras em disco e melhorar a latência.

O vm.swappiness do Linux impacta o desempenho do MySQL?

Sim. O parâmetro vm.swappiness controla a tendência do kernel Linux de mover páginas de memória para o swap. Para servidores MySQL dedicados, recomenda-se um valor baixo, como vm.swappiness = 10, para que o kernel prefira manter o buffer pool do InnoDB em RAM em vez de paginar para disco. Configure no /etc/sysctl.conf com vm.swappiness = 10 e aplique sem reinicialização com sudo sysctl -p. Valores altos de swappiness em servidores com carga intensa costumam causar degradação severa de latência.

O firewalld pode impactar o desempenho do MySQL?

O firewalld não afeta o throughput do MySQL de forma mensurável: ele realiza filtragem stateful por conntrack, não inspeção profunda de pacotes. A principal motivação para restringir a porta 3306 por origem é segurança, não desempenho. Para liberar o acesso apenas a hosts confiáveis, use um rich rule e recarregue as regras:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="3306" accept'
sudo firewall-cmd --reload

Substitua 192.168.1.0/24 pela faixa de IP dos servidores de aplicação que precisam acessar o banco.

Preciso reiniciar o MySQL após alterar o my.cnf?

Alterações feitas somente no my.cnf entram em vigor no próximo reinício do serviço. No entanto, innodb_buffer_pool_size e max_connections são variáveis dinâmicas e podem ser aplicadas imediatamente com SET GLOBAL ou persistidas com SET PERSIST, que grava em mysqld-auto.cnf e sobrevive ao reinício sem necessidade de editar o my.cnf. Variáveis não dinâmicas, como innodb_flush_method e innodb_read/write_io_threads, continuam exigindo reinício do serviço.

Conclusão

Otimizar o MySQL 8.0 no Fedora 44 para alta carga exige ajustes coordenados de memória, conexões e I/O, não apenas um único parâmetro isolado.

• Dimensione o innodb_buffer_pool_size com base na RAM real disponível e monitore a taxa de acerto
• Calibre max_connections e thread_cache_size conforme o padrão de conexões da sua aplicação
• Use o slow_query_log continuamente para capturar regressões de performance antes que virem incidentes

Leia também

• Manual do InnoDB: tuning de buffer pool e I/O no MySQL 8.0
• Como otimizar o MySQL para alta performance no VPS Linux (com exemplos reais)
• Como otimizar o MySQL para alta performance em VPS Linux: guia completo

Precisa de ajuda com tuning de MySQL?

Se o ajuste manual não resolver os picos de carga ou você precisar de mais recursos dedicados ao banco, pode ser hora de migrar para uma infraestrutura com mais memória e I/O garantido.

Conheça os planos de VPS da AviraHost