Otimizar MariaDB 10.11 no Rocky Linux 9: tuning essencial

16 min de leitura  ·  Guia técnico

Otimizar MariaDB 10.11 no Rocky Linux 9 significa ajustar variáveis de configuração, parâmetros de memória e comportamento do InnoDB para extrair o máximo de desempenho do banco de dados sem comprometer a estabilidade do servidor. Para aplicar o tuning essencial, siga estes passos:

1. Instale e verifique a versão do MariaDB 10.11 no Rocky Linux 9
2. Edite o arquivo /etc/my.cnf.d/server.cnf com os parâmetros de memória e InnoDB
3. Ajuste innodb_buffer_pool_size, innodb_log_file_size e max_connections
4. Ative o slow query log para identificar consultas problemáticas
5. Reinicie o MariaDB e valide as variáveis com SHOW VARIABLES e SHOW STATUS
6. Monitore continuamente com ferramentas como mysqltuner e mytop

Pré-requisitos para otimizar MariaDB 10.11 no Rocky Linux 9

• Acesso root ou sudo ao servidor Rocky Linux 9
• MariaDB 10.11 instalado e em execução (systemctl status mariadb)
• Conhecimento básico de SQL e edição de arquivos de configuração via terminal
• RAM mínima recomendada: 2 GB (4 GB ou mais para ambientes de produção)
• Backup recente do banco de dados antes de qualquer alteração de configuração
• Acesso SSH ao servidor — veja como em Acessando servidores VPS Linux da AviraHost

Verificando a instalação e coletando métricas iniciais do MariaDB

Antes de alterar qualquer parâmetro de performance do MariaDB, é fundamental coletar uma linha de base. Sem métricas iniciais, você não saberá se o tuning realmente melhorou algo. Comece confirmando a versão instalada e o estado atual do serviço:

mariadb --version
systemctl status mariadb

mariadb  Ver 15.1 Distrib 10.11.x-MariaDB, for Linux (x86_64)
● mariadb.service - MariaDB 10.11 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled)
     Active: active (running) since ...

Em seguida, acesse o cliente MariaDB e colete as variáveis globais atuais:

mariadb -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'innodb%';"
mariadb -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';"

Anote os valores de innodb_buffer_pool_size, innodb_log_file_size e innodb_io_capacity. Esses serão os pontos de comparação após o tuning. Verifique também a RAM total disponível no servidor:

free -h

              total        used        free      shared  buff/cache   available
Mem:           7.6Gi       1.2Gi       5.1Gi        45Mi       1.3Gi       6.1Gi
Swap:          2.0Gi          0B       2.0Gi

Com 7,6 GB de RAM, por exemplo, o innodb_buffer_pool_size ideal para um servidor dedicado ao banco de dados ficaria entre 5 GB e 6 GB. Para um VPS com outros serviços rodando, use entre 3 GB e 4 GB. Consulte também as Dicas de Otimização de Servidores Linux para ajustes complementares no sistema operacional.

Editando o arquivo de configuração principal do MariaDB 10.11

O arquivo de configuração do MariaDB no Rocky Linux 9 fica em /etc/my.cnf.d/server.cnf. Diferente de distribuições baseadas em Debian, o Rocky Linux usa o diretório my.cnf.d para fragmentos de configuração, o que facilita a organização. Faça um backup antes de editar:

Atenção: Sempre faça backup do arquivo de configuração antes de modificá-lo. Uma configuração inválida pode impedir o MariaDB de iniciar.

cp /etc/my.cnf.d/server.cnf /etc/my.cnf.d/server.cnf.bak
nano /etc/my.cnf.d/server.cnf

Adicione ou ajuste os seguintes parâmetros na seção [mysqld]:

[mysqld]

# === MEMÓRIA E INNODB ===
innodb_buffer_pool_size         = 4G
innodb_buffer_pool_instances    = 4
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 64M
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method             = O_DIRECT
innodb_io_capacity              = 400
innodb_io_capacity_max          = 800
innodb_read_io_threads          = 4
innodb_write_io_threads         = 4

# === CONEXÕES ===
max_connections                 = 200
thread_cache_size               = 50
wait_timeout                    = 300
interactive_timeout             = 300

# === CACHE E BUFFERS ===
table_open_cache                = 4000
table_definition_cache          = 2000
query_cache_type                = 0
query_cache_size                = 0
tmp_table_size                  = 64M
max_heap_table_size             = 64M
join_buffer_size                = 4M
sort_buffer_size                = 4M
read_rnd_buffer_size            = 2M

# === SLOW QUERY LOG ===
slow_query_log                  = 1
slow_query_log_file             = /var/log/mariadb/slow.log
long_query_time                 = 1
log_queries_not_using_indexes   = 1

# === CHARSET ===
character_set_server            = utf8mb4
collation_server                = utf8mb4_unicode_ci

Salve o arquivo e valide a sintaxe antes de reiniciar:

mariadbd --user=mysql --validate-config

2024-xx-xx xx:xx:xx 0 [Note] mariadbd: ready for connections.

Se não houver erros, reinicie o serviço:

systemctl restart mariadb
systemctl status mariadb

Ajustando parâmetros InnoDB para máxima performance de leitura e escrita

O motor InnoDB do MariaDB é responsável pela maior parte do desempenho em aplicações web modernas. Entender cada parâmetro evita configurações que parecem corretas mas causam degradação em produção.

innodb_buffer_pool_instances: Quando o innodb_buffer_pool_size é maior que 1 GB, divida o pool em múltiplas instâncias para reduzir contenção de mutex. Use 1 instância por GB, com máximo de 8. Para 4 GB, use 4 instâncias.

innodb_flush_log_at_trx_commit: O valor padrão 1 garante durabilidade total (ACID), mas força um fsync a cada transação. O valor 2 faz flush para o cache do SO a cada transação e para disco a cada segundo — aceitável para a maioria das aplicações web e oferece ganho significativo de throughput. Use 0 apenas em ambientes de teste.

innodb_flush_method = O_DIRECT: Evita double buffering entre o buffer pool do InnoDB e o page cache do Linux. Essencial em servidores com muita RAM para evitar desperdício de memória.

innodb_io_capacity: Representa o número de operações de I/O por segundo disponíveis para o InnoDB. Para SSDs SATA, use entre 400 e 800. Para NVMe, pode-se usar 2000 ou mais. Para HDDs, mantenha entre 100 e 200.

Após reiniciar, confirme que os valores foram aplicados:

mariadb -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 4294967296 |
+-------------------------+------------+

O valor 4294967296 corresponde a 4 GB em bytes, confirmando que a configuração foi aplicada corretamente.

Ativando e analisando o slow query log para identificar gargalos

O slow query log do MariaDB é uma das ferramentas mais valiosas para identificar consultas que consomem recursos excessivos. Com long_query_time = 1, qualquer query que demore mais de 1 segundo será registrada. Para ambientes de alta carga, considere reduzir para 0.5 segundos.

Verifique se o diretório de log existe e tem permissões corretas:

mkdir -p /var/log/mariadb
chown mysql:mysql /var/log/mariadb
chmod 750 /var/log/mariadb

Após alguns minutos de operação, analise o log com o mysqldumpslow:

mysqldumpslow -s t -t 10 /var/log/mariadb/slow.log

Reading mysql slow query log from /var/log/mariadb/slow.log
Count: 45  Time=3.21s (144s)  Lock=0.00s (0s)  Rows=1250.0 (56250), user@host
  SELECT * FROM pedidos WHERE status = 'pendente' ORDER BY criado_em DESC

Esse output indica que a query foi executada 45 vezes, com tempo médio de 3,21 segundos. A solução imediata é adicionar um índice composto:

mariadb -u root -p nome_do_banco -e "
  ALTER TABLE pedidos ADD INDEX idx_status_criado (status, criado_em DESC);"

Para uma análise mais completa, instale e execute o mysqltuner:

curl -L https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl -o mysqltuner.pl
perl mysqltuner.pl --user root --pass sua_senha

O mysqltuner analisa dezenas de variáveis e gera recomendações específicas para o seu ambiente, incluindo sugestões de índices ausentes e configurações de memória.

Otimizando conexões e threads no MariaDB para ambientes de alta concorrência

O gerenciamento de conexões simultâneas no MariaDB é crítico em aplicações com muitos usuários concorrentes, como e-commerces e sistemas SaaS. Cada conexão aberta consome memória, e um número excessivo de conexões pode esgotar a RAM disponível.

Para verificar o uso atual de conexões em tempo real:

mariadb -u root -p -e "SHOW STATUS LIKE 'Threads_%';"

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 48    |
| Threads_connected | 12    |
| Threads_created   | 60    |
| Threads_running   | 3     |
+-------------------+-------+

Se Threads_created cresce continuamente, o thread_cache_size está baixo. O valor ideal é próximo ao pico de Threads_connected observado. Ajuste em tempo real sem reiniciar:

mariadb -u root -p -e "SET GLOBAL thread_cache_size = 100;"

Para max_connections, calcule com base na RAM disponível para o MariaDB. Se você reservou 4 GB para o banco e cada conexão consome em média 4 MB, o limite seguro é aproximadamente 1000 conexões. Na prática, mantenha uma margem de segurança e use 200 a 400 para a maioria dos VPS de produção.

O parâmetro wait_timeout controla por quantos segundos uma conexão inativa é mantida aberta. O padrão de 28800 segundos (8 horas) é excessivo para aplicações web — reduza para 300 segundos para liberar conexões ociosas rapidamente.

Você pode alterar max_connections em tempo real:

mariadb -u root -p -e "SET GLOBAL max_connections = 300;"

Lembre-se de também atualizar o valor no server.cnf para persistir após reinicializações.

Problemas comuns e como resolver

Sintoma: MariaDB não inicia após editar o server.cnf

Causa: Erro de sintaxe no arquivo de configuração, parâmetro inválido para a versão 10.11, ou valor de memória maior que a RAM disponível no servidor.
Solução: Execute mariadbd --user=mysql --validate-config para identificar a linha com erro. Verifique também o journal do systemd com journalctl -u mariadb -n 50 --no-pager. Se necessário, restaure o backup: cp /etc/my.cnf.d/server.cnf.bak /etc/my.cnf.d/server.cnf e reinicie o serviço.

Sintoma: Alto uso de swap mesmo com innodb_buffer_pool_size configurado

Causa: O valor de innodb_buffer_pool_size foi definido muito alto, deixando pouca memória para o sistema operacional, outras aplicações e os buffers de conexão do próprio MariaDB. O Linux começa a usar swap para compensar.
Solução: Reduza o innodb_buffer_pool_size em 10% a 20%. Verifique o consumo real com free -h após o restart e monitore o swap com vmstat 5 10. Em VPS com 4 GB de RAM rodando também Nginx e PHP-FPM, mantenha o buffer pool em no máximo 1,5 GB a 2 GB.

Sintoma: Queries lentas mesmo após adicionar índices

Causa: O otimizador de queries pode não estar usando os índices criados, especialmente se as estatísticas de tabela estiverem desatualizadas. Também pode ser contenção de I/O se o innodb_io_capacity estiver subdimensionado para o tipo de disco.
Solução: Execute ANALYZE TABLE nome_tabela; para atualizar as estatísticas. Use EXPLAIN SELECT ... para verificar se o índice está sendo utilizado. Se o problema for I/O, aumente innodb_io_capacity com SET GLOBAL innodb_io_capacity = 800; e monitore com iostat -x 5.

Sintoma: Erro "Too many connections" nas aplicações

Causa: O número de conexões simultâneas atingiu o limite definido em max_connections. Isso pode ocorrer por conexões não fechadas corretamente pela aplicação ou por picos de tráfego.
Solução: Verifique o pico histórico com SHOW GLOBAL STATUS LIKE 'Max_used_connections';. Aumente max_connections com SET GLOBAL max_connections = 400; e implemente connection pooling na aplicação (ProxySQL ou PgBouncer equivalente para MySQL). Reduza wait_timeout para fechar conexões ociosas mais rapidamente.

Perguntas frequentes sobre otimização do MariaDB 10.11

Qual o tamanho ideal do innodb_buffer_pool_size no MariaDB?

Em servidores dedicados exclusivamente ao banco de dados, o valor recomendado é entre 70% e 80% da RAM total disponível. Em VPS compartilhado com outros serviços, use entre 40% e 60% para evitar que o MariaDB consuma toda a memória e cause swap excessivo. Por exemplo, em um servidor com 8 GB de RAM dedicado ao banco, configure innodb_buffer_pool_size = 6G.

Como verificar se o tuning do MariaDB está funcionando?

Execute SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests' e SHOW STATUS LIKE 'Innodb_buffer_pool_reads' no cliente MySQL. A taxa de acerto do buffer pool deve ser superior a 99% — calcule dividindo as leituras do pool pelo total de requisições. Você também pode usar SHOW GLOBAL STATUS LIKE 'Slow_queries' para monitorar consultas lentas após ativar o slow query log e comparar com a linha de base coletada antes do tuning.

O query cache do MariaDB ainda vale a pena ativar?

No MariaDB 10.11, o query cache está presente mas é desativado por padrão (query_cache_type=0) porque em cargas de trabalho com muitas escritas ele causa contenção de mutex e degrada a performance. Para workloads predominantemente de leitura com dados pouco alterados, ativá-lo com query_cache_size entre 32M e 128M pode ajudar, mas o uso de Redis ou Memcached é geralmente mais eficiente e escalável para esse propósito.

Como limitar o número máximo de conexões simultâneas no MariaDB?

Defina max_connections no arquivo /etc/my.cnf.d/server.cnf. O valor padrão é 151, mas cada conexão consome entre 1 MB e 8 MB de RAM dependendo das operações em execução. Calcule o valor máximo seguro dividindo a RAM disponível para o MariaDB pelo consumo médio por conexão e reinicie o serviço com systemctl restart mariadb. Para alterações imediatas sem restart, use SET GLOBAL max_connections = 300;.

É necessário reiniciar o MariaDB para aplicar todas as configurações de tuning?

Algumas variáveis podem ser alteradas em tempo real com SET GLOBAL, como innodb_io_capacity e max_connections, sem reiniciar o serviço. Porém, variáveis como innodb_buffer_pool_size (em versões anteriores ao MariaDB 10.2) e innodb_log_file_size exigem reinicialização completa do daemon para ter efeito. Sempre valide com SHOW VARIABLES após o restart para confirmar que os novos valores foram carregados.

Conclusão

• Comece pela coleta de métricas: nunca ajuste parâmetros sem uma linha de base — use SHOW STATUS, SHOW VARIABLES e o slow query log para identificar os reais gargalos antes de qualquer mudança.
• Priorize o innodb_buffer_pool_size: é o parâmetro com maior impacto no desempenho do MariaDB — configure entre 40% e 80% da RAM disponível conforme o perfil do servidor, e divida em múltiplas instâncias para reduzir contenção.
• Valide e monitore continuamente: use mysqltuner semanalmente, monitore a taxa de acerto do buffer pool e revise o slow query log regularmente para manter o banco de dados performático à medida que os dados crescem.

Leia também

• Otimizar MariaDB 10.11 no Debian 12: tuning essencial
• 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 banco de dados no seu servidor?

Configurar e otimizar o MariaDB em produção exige atenção a detalhes que variam conforme o hardware, o volume de dados e o perfil de acesso da sua aplicação. Um VPS bem dimensionado e configurado pode fazer toda a diferença no tempo de resposta do seu sistema.

Conheça os planos de VPS da AviraHost com suporte técnico especializado