Otimizar MariaDB 10.11 no Debian 12: tuning essencial

21 min de leitura  ·  Guia técnico

Otimizar MariaDB 10.11 no Debian 12 significa ajustar parâmetros de configuração do servidor de banco de dados para reduzir latência de consultas, aumentar o aproveitamento de memória e melhorar a taxa de acerto do buffer pool. Para aplicar o tuning essencial, siga estes passos:

1. Verificar o estado atual do MariaDB e coletar métricas de baseline
2. Editar o arquivo /etc/mysql/mariadb.conf.d/50-server.cnf com os parâmetros otimizados
3. Ajustar innodb_buffer_pool_size, innodb_log_file_size e parâmetros de conexão
4. Ativar e configurar o slow query log para identificar gargalos
5. Recarregar ou reiniciar o serviço e validar as configurações aplicadas
6. Monitorar métricas de status para confirmar a melhora de desempenho

Pré-requisitos para otimizar o MariaDB 10.11 no Debian 12

• Sistema operacional: Debian 12 (Bookworm) com MariaDB 10.11 instalado via repositório oficial
• Acesso: usuário root ou com privilégios sudo no sistema e acesso ao cliente mariadb como root do banco
• RAM disponível: mínimo 2 GB; recomendado 4 GB ou mais para tuning efetivo do InnoDB
• Editor de texto: nano ou vim instalado
• Backup recente: realize um dump completo antes de alterar qualquer parâmetro de configuração
• Conhecimento básico: familiaridade com systemd e edição de arquivos de configuração no Linux

Coletando métricas de baseline antes do tuning do MariaDB

Antes de alterar qualquer parâmetro de desempenho do MariaDB, é fundamental registrar o estado atual do servidor para comparar os resultados após as mudanças. Sem um baseline, é impossível saber se o tuning gerou ganho real ou introduziu regressão.

Conecte-se ao cliente MariaDB como root:

mariadb -u root -p

Dentro do cliente, execute os seguintes comandos para capturar variáveis e status relevantes:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'query_cache_type';
SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Slow_queries';

Salve o output em um arquivo de texto para referência futura. A taxa de acerto do buffer pool é calculada como:

Taxa de acerto = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)

Se a taxa de acerto estiver abaixo de 95%, o innodb_buffer_pool_size está subdimensionado para a carga atual. Esse é o primeiro indicador de que o tuning trará ganhos imediatos.

Verifique também a RAM total disponível no servidor:

free -h

Output esperado:
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.2Gi       4.1Gi        45Mi       2.5Gi       6.3Gi
Swap:          2.0Gi          0B       2.0Gi

Com esses dados em mãos, você tem a base necessária para dimensionar corretamente cada parâmetro. Para mais contexto sobre como servidores VPS se comportam sob carga de banco de dados, consulte o artigo Compreendendo o Servidor VPS: O que é e Como Funciona!.

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

O ajuste fino de parâmetros InnoDB é feito no arquivo de configuração do servidor, que no Debian 12 com MariaDB 10.11 fica em /etc/mysql/mariadb.conf.d/50-server.cnf. Esse arquivo tem precedência sobre o my.cnf global e é o local correto para personalizações de produção.

Atenção: Faça backup do arquivo antes de editar. Erros de sintaxe neste arquivo impedem o MariaDB de iniciar.

cp /etc/mysql/mariadb.conf.d/50-server.cnf /etc/mysql/mariadb.conf.d/50-server.cnf.bak

Abra o arquivo para edição:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Localize a seção [mysqld] e adicione ou ajuste os seguintes parâmetros. Os valores abaixo são calibrados para um servidor com 4 GB de RAM rodando MariaDB como serviço principal, com Nginx e PHP-FPM também ativos:

[mysqld]

# --- InnoDB Buffer Pool ---
innodb_buffer_pool_size         = 1G
innodb_buffer_pool_instances    = 2
innodb_buffer_pool_chunk_size   = 128M

# --- InnoDB Log ---
innodb_log_file_size            = 256M
innodb_log_buffer_size          = 64M
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method             = O_DIRECT

# --- Conexões e Threads ---
max_connections                 = 150
thread_cache_size               = 16
table_open_cache                = 4000
table_definition_cache          = 2000

# --- Temporários e Sort ---
tmp_table_size                  = 64M
max_heap_table_size             = 64M
sort_buffer_size                = 2M
join_buffer_size                = 2M
read_rnd_buffer_size            = 1M

# --- Slow Query Log ---
slow_query_log                  = 1
slow_query_log_file             = /var/log/mysql/mariadb-slow.log
long_query_time                 = 1
log_queries_not_using_indexes   = 0

# --- Charset ---
character-set-server            = utf8mb4
collation-server                = utf8mb4_unicode_ci

Salve o arquivo com Ctrl+O e saia com Ctrl+X.

Entendendo cada parâmetro de tuning do MariaDB

innodb_buffer_pool_size: É o parâmetro mais impactante. Armazena dados e índices InnoDB em memória, reduzindo leituras em disco. Em servidores dedicados ao banco de dados, pode chegar a 70% da RAM total.

innodb_buffer_pool_instances: Divide o buffer pool em múltiplas instâncias para reduzir contenção de mutex em ambientes com alta concorrência. Recomenda-se 1 instância por GB de buffer pool, até o máximo de 8.

innodb_flush_log_at_trx_commit = 2: Reduz operações de fsync por segundo ao custo de perder até 1 segundo de transações em caso de crash do sistema operacional (não do MariaDB). Aceitável para a maioria das aplicações web; use 1 apenas se ACID estrito for obrigatório.

innodb_flush_method = O_DIRECT: Evita double buffering entre o buffer pool do InnoDB e o page cache do kernel Linux, reduzindo uso de memória e melhorando throughput de I/O em discos SSD.

max_connections: Cada conexão consome entre 1 MB e 5 MB de RAM. Dimensione com base na carga real, não no máximo teórico. Conexões ociosas em excesso desperdiçam recursos.

Validando e aplicando as configurações de performance do MariaDB

Antes de reiniciar o serviço, valide a sintaxe do arquivo de configuração para evitar falhas de inicialização. O MariaDB oferece uma flag específica para isso:

mariadbd --user=mysql --verbose --help 2>&1 | head -50

Se não houver erros de sintaxe, o comando retornará a lista de opções sem mensagens de erro. Caso apareça algo como unknown variable ou syntax error, corrija antes de prosseguir.

Para alterações que não exigem reinício completo, tente o reload:

systemctl reload mariadb

Para parâmetros como innodb_buffer_pool_size e innodb_log_file_size, é necessário reinício completo. Faça isso durante uma janela de manutenção:

systemctl restart mariadb

Verifique se o serviço voltou ao ar corretamente:

systemctl status mariadb

Output esperado:
● mariadb.service - MariaDB 10.11.6 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-11-04 14:32:11 UTC; 5s ago
    Process: 12345 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
   Main PID: 12350 (mariadbd)
     Status: "Taking your SQL requests now..."

Agora confirme que os parâmetros foram aplicados dentro do cliente MariaDB:

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

Output esperado:
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 1073741824 |
+-------------------------+------------+

O valor 1073741824 corresponde a 1 GB em bytes, confirmando que a configuração foi aplicada com sucesso.

Ativando e analisando o slow query log para identificar consultas lentas

O slow query log é uma das ferramentas mais valiosas para diagnóstico de gargalos de desempenho em bancos de dados MariaDB. Com ele ativo, você identifica quais consultas SQL consomem mais tempo e podem se beneficiar de índices ou reescrita.

Certifique-se de que o diretório de log existe e tem as permissões corretas:

mkdir -p /var/log/mysql
chown mysql:mysql /var/log/mysql

Com as configurações do slow query log já inseridas no 50-server.cnf (conforme a seção anterior), após o reinício do MariaDB o log estará ativo. Para verificar:

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

Output esperado:
+---------------------+----------------------------------+
| Variable_name       | Value                            |
+---------------------+----------------------------------+
| slow_query_log      | ON                               |
| slow_query_log_file | /var/log/mysql/mariadb-slow.log  |
+---------------------+----------------------------------+

Para analisar o log de forma eficiente, use a ferramenta mysqldumpslow incluída no pacote MariaDB:

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

O parâmetro -s t ordena por tempo total e -t 10 exibe as 10 consultas mais lentas. Ao rodar este comando, você verá um resumo agrupado das queries problemáticas, incluindo o tempo médio de execução e o número de ocorrências.

Para consultas identificadas como lentas, verifique o plano de execução com EXPLAIN:

EXPLAIN SELECT * FROM pedidos WHERE status = 'pendente' AND criado_em > '2024-01-01';

Se a coluna type do output mostrar ALL (full table scan), a consulta precisa de um índice composto nas colunas status e criado_em.

Para referência adicional sobre otimização de servidores Linux em geral, veja o artigo Dicas de Otimização de Servidores Linux.

Ajustes adicionais de sistema operacional para melhorar o desempenho do MariaDB

O tuning de banco de dados não se limita ao arquivo de configuração do MariaDB. Parâmetros do kernel Linux e configurações de sistema operacional no Debian 12 também afetam diretamente o throughput de I/O e a latência de memória.

Desativando Transparent Huge Pages para o MariaDB

O Transparent Huge Pages (THP) do kernel Linux pode causar latência imprevisível em workloads de banco de dados devido à desfragmentação de memória em background. Desative-o para o MariaDB:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

Para tornar a configuração persistente entre reinicializações, adicione ao /etc/rc.local ou crie um serviço systemd dedicado. Verifique o estado atual com:

cat /sys/kernel/mm/transparent_hugepage/enabled

Output esperado:
always madvise [never]

O valor entre colchetes indica a opção ativa. [never] confirma que o THP está desativado.

Ajustando swappiness para reduzir uso de swap pelo MariaDB

O valor padrão de vm.swappiness = 60 no Debian 12 faz o kernel mover páginas de memória para swap prematuramente, o que degrada severamente a performance do InnoDB buffer pool. Para servidores de banco de dados, reduza para 10:

sysctl -w vm.swappiness=10

Para persistir após reboot, adicione ao /etc/sysctl.conf:

echo "vm.swappiness = 10" >> /etc/sysctl.conf
sysctl -p

Configurando o scheduler de I/O para SSDs

Se o servidor utiliza discos SSD (o que é padrão na maioria dos VPS modernos), o scheduler de I/O mais adequado é o none ou mq-deadline. Verifique o scheduler atual do disco principal:

cat /sys/block/sda/queue/scheduler

Output esperado:
[mq-deadline] kyber bfq none

Se o scheduler atual não for adequado para SSD, altere com:

echo mq-deadline > /sys/block/sda/queue/scheduler

Monitorando o desempenho do MariaDB após o tuning

Após aplicar todas as configurações, o monitoramento contínuo é essencial para validar os ganhos e detectar novos gargalos. O MariaDB expõe centenas de variáveis de status que permitem acompanhar o comportamento em tempo real.

Para calcular a taxa de acerto do buffer pool após o tuning:

mariadb -u root -p -e "
SELECT 
  ROUND(
    (1 - (
      (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') /
      (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
    )) * 100, 2
  ) AS buffer_pool_hit_rate_pct;"

Output esperado:
+------------------------+
| buffer_pool_hit_rate_pct |
+------------------------+
|                  98.74 |
+------------------------+

Uma taxa acima de 95% indica que o buffer pool está bem dimensionado para a carga atual. Se a taxa permanecer abaixo de 90% mesmo após o tuning, considere aumentar o innodb_buffer_pool_size ou migrar para um plano de VPS com mais RAM.

Monitore também o número de conexões abertas e o uso de threads:

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

Output esperado:
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 14    |
| Threads_connected | 8     |
| Threads_created   | 22    |
| Threads_running   | 2     |
+-------------------+-------+

Se Threads_created crescer continuamente ao longo do tempo, o thread_cache_size está subdimensionado. Aumente-o gradualmente e reavalie.

Problemas comuns e como resolver

Sintoma: MariaDB não inicia após editar o arquivo de configuração

Causa: Erro de sintaxe no arquivo 50-server.cnf, como um parâmetro digitado incorretamente, valor inválido ou seção [mysqld] duplicada.
Solução: Verifique os logs de erro com journalctl -u mariadb -n 50 --no-pager para identificar a linha problemática. Restaure o backup com cp /etc/mysql/mariadb.conf.d/50-server.cnf.bak /etc/mysql/mariadb.conf.d/50-server.cnf e aplique as alterações novamente com cuidado. Use mariadbd --verbose --help 2>&1 | grep -i error para validar a sintaxe antes de reiniciar.

Sintoma: Erro "Out of memory" ou MariaDB sendo morto pelo OOM Killer

Causa: O innodb_buffer_pool_size foi definido muito alto, consumindo RAM além do disponível quando somado ao uso de Apache, Nginx, PHP-FPM e outros processos.
Solução: Verifique os logs do kernel com dmesg | grep -i "oom\|killed" para confirmar que o OOM Killer atuou. Reduza o innodb_buffer_pool_size para 40-50% da RAM total se outros serviços estiverem ativos na mesma máquina. Considere também adicionar swap como safety net: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile.

Sintoma: Slow query log não está sendo gerado mesmo com a configuração ativa

Causa: O diretório /var/log/mysql/ não existe ou o usuário mysql não tem permissão de escrita nele.
Solução: Execute ls -la /var/log/mysql/ para verificar a existência e permissões do diretório. Se necessário, recrie com mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql && chmod 750 /var/log/mysql. Reinicie o MariaDB e verifique novamente com SHOW VARIABLES LIKE 'slow_query_log';.

Sintoma: Alta latência em consultas mesmo após o tuning do InnoDB

Causa: O gargalo pode estar em consultas sem índice adequado, tabelas MyISAM (que não se beneficiam do InnoDB buffer pool) ou contenção de locks em tabelas com alta concorrência de escrita.
Solução: Use SHOW ENGINE INNODB STATUS\G para identificar deadlocks e transações bloqueadas. Verifique se há tabelas MyISAM com SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'seu_banco' AND ENGINE = 'MyISAM'; e considere convertê-las para InnoDB com ALTER TABLE nome_tabela ENGINE=InnoDB;.

Sintoma: Número de conexões atingindo o limite máximo (max_connections)

Causa: A aplicação não está usando connection pooling, abrindo uma nova conexão para cada requisição HTTP, ou há conexões zumbi acumuladas.
Solução: Verifique conexões ativas com SHOW PROCESSLIST;. Implemente connection pooling na aplicação (PDO persistent connections no PHP, HikariCP no Java). Ajuste wait_timeout e interactive_timeout para 300 segundos para encerrar conexões ociosas mais rapidamente: adicione wait_timeout = 300 e interactive_timeout = 300 ao arquivo de configuração.

Perguntas frequentes sobre otimização do MariaDB 10.11

Qual o valor ideal de innodb_buffer_pool_size para o MariaDB no Debian 12?

O valor recomendado é entre 50% e 70% da RAM total disponível no servidor, desde que o sistema não execute outros serviços pesados simultaneamente. Em um servidor com 4 GB de RAM dedicado ao banco de dados, defina innodb_buffer_pool_size = 2G. Ajuste para baixo se Apache, Nginx ou PHP-FPM também estiverem ativos na mesma máquina, pois esses serviços competem pela mesma memória física.

Como verificar se o MariaDB está usando as configurações de tuning aplicadas?

Execute SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; dentro do cliente MariaDB para confirmar o valor ativo. Você também pode usar SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests'; e comparar com Innodb_buffer_pool_reads para calcular a taxa de acerto do buffer pool. Quanto mais próxima de 100% essa taxa estiver, melhor o aproveitamento da memória configurada.

O slow query log do MariaDB impacta a performance do servidor?

O impacto é mínimo em produção quando configurado corretamente. Defina long_query_time entre 1 e 2 segundos para capturar apenas consultas realmente lentas. Ativar o log com threshold muito baixo, como 0.1 segundo, pode gerar volume excessivo de escrita em disco e degradar a performance em servidores com alto número de requisições simultâneas.

Como reiniciar o MariaDB no Debian 12 sem derrubar conexões ativas abruptamente?

Use o comando systemctl reload mariadb para recarregar configurações que suportam reload dinâmico sem encerrar conexões existentes. Para alterações que exigem reinício completo, como mudanças no innodb_buffer_pool_size, execute systemctl restart mariadb durante uma janela de manutenção planejada. Verifique o status com systemctl status mariadb após o comando para confirmar que o serviço voltou ao ar sem erros.

O MariaDB 10.11 no Debian 12 tem query cache ativado por padrão?

Não. O query cache foi removido do MariaDB a partir da versão 10.9 por causar contenção de mutex em ambientes com alta concorrência de escrita, o que paradoxalmente degradava a performance em vez de melhorá-la. Em vez disso, utilize cache em camada de aplicação com Redis ou Memcached, ou implemente ProxySQL para cache de consultas em nível de proxy de banco de dados.

Conclusão

Aplicar tuning no MariaDB 10.11 no Debian 12 é um processo iterativo que combina ajustes de configuração do banco de dados com otimizações no nível do sistema operacional. Os principais pontos de ação são:

• Dimensione o innodb_buffer_pool_size corretamente: use entre 50% e 70% da RAM disponível para o MariaDB, ajustando conforme outros serviços ativos no mesmo servidor. Monitore a taxa de acerto do buffer pool regularmente e ajuste conforme o crescimento da base de dados.
• Use o slow query log como ferramenta de diagnóstico contínuo: com long_query_time = 1, você captura consultas problemáticas sem impacto significativo em produção. Analise o log semanalmente com mysqldumpslow e adicione índices nas consultas identificadas.
• Combine tuning de MariaDB com ajustes de kernel: desative Transparent Huge Pages, reduza vm.swappiness para 10 e configure o scheduler de I/O adequado para SSD. Esses ajustes complementam o tuning do banco de dados e podem reduzir a latência de I/O de forma significativa.

Leia também

• 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
• Otimizar a Performance de VPS Linux e Servidor Dedicado com Configuração Avançada do Kernel

Precisa de ajuda com tuning de MariaDB no seu servidor?

Configurar e otimizar bancos de dados em produção exige atenção a detalhes que variam conforme a carga da aplicação, o hardware disponível e os padrões de acesso aos dados. Um VPS bem dimensionado é a base para que o tuning do MariaDB produza resultados reais.

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