Execute o Debian 12 em um VPS com pouca RAM sem que travamentos por falta de memória derrubem o MySQL.

Um VPS com pouca memória pode executar o Debian 12 e um banco de dados, mas a estabilidade depende de toda a carga de trabalho — não apenas do cache configurado do MySQL. Quando a memória disponível se esgota, o Linux pode invocar o mecanismo de eliminação de processos por falta de memória (OOM killer), que encerra um processo para proteger o restante do sistema. Se esse processo for o banco de dados, o sintoma pode parecer uma falha aleatória. O objetivo prático é evitar a pressão contínua na memória e confirmar qual processo o kernel realmente encerrou; nenhuma configuração de otimização pode garantir que eventos de falta de memória nunca ocorrerão.

O Debian 12 está executando MySQL ou MariaDB?

Verifique o servidor antes de alterar sua configuração. O Debian 12 (Bookworm) usa o MariaDB como default-mysql-serverpacote padrão; o Oracle MySQL possui um caminho de instalação separado. As informações de pacotes do Debian listam o MariaDB como dependência de servidor desse metapacote. Execute:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

Use as instruções do MariaDB abaixo somente se o serviço instalado for o MariaDB. O Oracle MySQL usa nomes de opções com aparência semelhante em muitos casos, mas os layouts de pacotes, nomes de serviços, variáveis ​​disponíveis e valores padrão podem ser diferentes. Consulte o manual para obter informações sobre a versão exata do MySQL instalada.

Referências principais: Pacote default-mysql-server do Debian Bookworm e o manual de uso de memória do MySQL 8.0 .

Como saber se a falta de memória (OOM) causou a falha do banco de dados?

Primeiro, diferencie um erro de falta de memória (OOM kill) do kernel de um erro de banco de dados, reinicialização de serviço, reinicialização do sistema ou problema de disco. No Debian, o journalctlsistema lê o journal do systemd. Procure na inicialização atual e inspecione o log de serviço do MariaDB:

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

Se os nomes dos logs do kernel mariadbdindicarem mysqlduma mensagem de falta de memória (OOM), isso indica que houve uma interrupção abrupta do processo devido à falta de memória. Caso não haja nenhuma entrada correspondente, verifique o log de erros do próprio serviço e o histórico de reinicializações ou monitoramento do provedor. Os logs podem ficar indisponíveis após uma reinicialização se o registro em diário não for persistente, e um provedor de VPS gerenciado pode expor apenas parte dos diagnósticos do host.

Registre uma linha de base enquanto o servidor estiver sob tráfego representativo, não apenas quando ocioso:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

Em ` vmstat/etc/fstab`, observe as sicolunas so`swap` e `swapout` para verificar a atividade contínua de swap-in e swap-out. Uma alocação de swap diferente de zero por si só não indica um problema; swaps contínuos, juntamente com tempos de resposta lentos, indicam pressão na memória. O Linux documenta o tratamento de falta de memória (OOM) como uma resposta de último recurso quando a memória não pode ser recuperada suficientemente. Consulte os conceitos de gerenciamento de memória do kernel Linux e o manual do `journalctl` do Debian .

O que você deve medir antes de afinar?

Registre o uso total de RAM, o uso atual e máximo de swap, os maiores processos residentes, as conexões com o banco de dados e o pico normal de uso da aplicação web. O banco de dados compartilha memória com o Debian, o servidor web, os workers da aplicação, os agentes de monitoramento e o cache do sistema de arquivos. Um VPS também pode ter um limite de memória para contêineres ou cgroups inferior à RAM física do host; dimensione os caches do banco de dados de acordo com o limite de memória visível para o serviço, e não com um limite total maior que o do host.

Para o MariaDB, verifique as configurações atuais relacionadas à memória e o pico de conexão:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

O pool de buffers do InnoDB armazena em cache páginas de tabelas e índices. Limites de conexão e buffers de consulta podem aumentar a demanda de memória à medida que o trabalho simultâneo aumenta. Evite multiplicar cada buffer por conexão como max_connectionsse cada buffer estivesse sempre totalmente alocado, mas considere um limite de conexão muito alto como um risco em picos de uso. O guia de memória do MariaDB recomenda dimensionar caches globais, buffers por conexão e configurações do mecanismo em conjunto, e menciona especificamente os pools de conexão do aplicativo. Leia o guia de alocação de memória do MariaDB e o guia para lidar com um número excessivo de conexões .

Como dimensionar corretamente o MariaDB em um VPS pequeno?

Faça uma alteração por vez, mantenha uma cópia da configuração original e teste durante uma janela de manutenção se uma reinicialização afetaria os usuários. A configuração do MariaDB incluída no pacote Debian geralmente inclui arquivos em `/etc/mariadb` /etc/mysql/mariadb.conf.d/; verifique os diretórios de inclusão ativos em sua instalação antes de editar. Um pequeno arquivo de substituição é mais fácil de remover do que substituir o arquivo principal do fornecedor.

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

Para um VPS compartilhado com cerca de 1 GiB de RAM, o exemplo a seguir é apenas uma sugestão inicial cautelosa — não um perfil seguro universal. Ajuste os valores para cima ou para baixo com base no pico de memória medido, no tamanho do banco de dados, na carga de trabalho e na RAM disponível para o sistema operacional e os aplicativos.

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

O MariaDB lê as configurações dos arquivos de opções na inicialização; verifique os nomes das seções suportadas e os valores efetivos da sua versão. Se este arquivo não carregar, remova o arquivo de configuração adicional e revise o registro de alterações. Reiniciar o banco de dados interrompe as conexões existentes, portanto, agende a reinicialização adequadamente.

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

Avalie o resultado considerando tanto a estabilidade quanto a qualidade do serviço. Um pool de buffers menor pode reduzir os acertos de cache e aumentar as leituras de disco. Reduzir max_connectionsdemais pode, em vez disso, gerar erros de "Muitas conexões". Compare Max_used_connectionscom o limite configurado e revise os tamanhos do pool de aplicativos antes de alterar esse limite novamente. Se o banco de dados ainda for interrompido durante picos de tráfego normais ou se o tempo de resposta piorar devido à troca constante de disco, migre para uma camada de RAM maior ou separe o banco de dados do aplicativo.

A troca de objetos (swap) pode prevenir uma falha por falta de memória (OOM)?

A área de swap oferece ao Linux um local mais lento para mover algumas páginas de memória e pode absorver picos momentâneos de uso. Ela não adiciona RAM rápida, não corrige vazamentos de memória nem torna um VPS com espaço insuficiente adequado para uma carga de trabalho contínua. O uso excessivo de swap pode tornar tanto o banco de dados quanto o aplicativo inoperantes. Verifique se seu provedor oferece suporte a arquivos de swap e se o VPS possui espaço em disco suficiente antes de criar um.

Se houver suporte, um arquivo de swap de 1 GiB pode ser criado da seguinte forma. Ajuste o tamanho de acordo com as orientações do provedor e o espaço em disco disponível e verifique o resultado de cada comando:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Para habilitá-lo após a reinicialização, adicione esta entrada /etc/fstabdepois de verificar se uma entrada equivalente já não está presente:

/swapfile none swap sw 0 0

Em seguida, valide o arquivo sudo findmnt --verify --verbosee confirme se ele aparece em swapon --show. Se fallocateo uso de swap não for suportado pelo sistema de arquivos ou se o provedor bloquear o swap, pare e use o procedimento suportado pelo provedor. Não desative o OOM killer nem atribua uma pontuação de proteção OOM extrema ao MySQL: isso não cria memória e pode deixar o restante de um VPS pequeno em maior risco.

Como você sabe se as mudanças funcionaram?

Observe o VPS durante pelo menos um período de uso normal. Um resultado útil apresenta vários sinais:

• Não foram detectadas novas entradas de OOM-kill no kernel durante a carga de trabalho que anteriormente desencadeou o incidente.
• O MariaDB permanece ativo e sua contagem de reinicializações não aumenta inesperadamente.
• vmstat 1Não apresenta troca contínua de memória (swap-in e swap-out) em condições normais de tráfego.
• O aplicativo continua respondendo e os picos de conexão com o banco de dados permanecem abaixo do novo limite, sem erros de conexão.
• Os backups foram concluídos e as consultas ao banco de dados continuam atendendo à latência aceitável do aplicativo.

Não use "o serviço inicia" como o único teste de sucesso. Uma configuração que mantém o MariaDB ativo, mas força o sistema a usar a memória virtual constantemente, não resolve o problema de capacidade subjacente. Da mesma forma, um dia tranquilo não valida uma importação mensal, um backup, um pico de tráfego ou um processo em lote que ainda não foi executado.

Quando é que o ajuste deixa de ser a solução adequada?

Escolha um VPS maior ou separe as cargas de trabalho quando a memória permanecer sob pressão mesmo após ajustes razoáveis ​​de cache e concorrência, a atividade de swap for constante, a latência de consulta se tornar inaceitável ou o aplicativo atingir repetidamente o limite de novas conexões. O tamanho do banco de dados também é importante: um pool de buffers muito pequeno pode evitar um pico de memória, mas transformar a E/S de disco no novo gargalo. Se o aplicativo e o banco de dados apresentarem picos acentuados, porém previsíveis, determine primeiro se o aplicativo está abrindo conexões em excesso ou executando tarefas que consomem muita memória simultaneamente.

Em servidores Oracle MySQL, em vez do MariaDB padrão do Debian, confirme o nome do serviço, o caminho do arquivo de opções e as variáveis ​​de memória consultando o manual do servidor antes de aplicar estes exemplos. Em ambos os servidores, mantenha backups testados e altere uma variável por vez. O resultado confiável não garante que o Linux nunca invocará o tratamento de erros de falta de memória (OOM); é uma evidência de que o VPS tem capacidade suficiente para sua carga de trabalho máxima real e que o MySQL ou o MariaDB não serão mais as vítimas recorrentes.

Referências primárias adicionais: Guia de resolução de problemas de inicialização do MariaDB , que observa que o servidor também precisa de memória para outros mecanismos, buffers por conexão e o sistema operacional, e o Manual de Referência do MySQL 8.0 .