Debian 12 em um VPS com pouca RAM: como reduzir as falhas de falta de memória (OOM) do MySQL

Você pode reduzir o risco de o processo OOM killer interromper o MySQL em um VPS Debian 12 com pouca RAM, confirmando a causa, gerenciando a memória entre todos os serviços, limitando a concorrência do banco de dados e disponibilizando swap onde o VPS permitir. Um pool de buffers InnoDB menor, por si só, não resolve o problema completamente. Nem o swap nem uma configuração de proteção contra OOM garantem que uma carga de trabalho excessiva continuará em execução.

Este guia foi pesquisado em 9 de outubro de 2026, usando Debian 12 “bookworm”, Linux 6.1 e documentação do Oracle MySQL 8.0/8.4. As configurações abaixo são pontos de partida ilustrativos, não resultados de benchmarks ou uma configuração universal. Faça backup do banco de dados e da configuração antes de fazer alterações e agende reinicializações do banco de dados para períodos de inatividade aceitáveis.

1. Identifique o servidor antes de copiar as configurações do MySQL.

Verificado: o pacote default-mysql-server do Debian 12 depende do MariaDB. Um VPS descrito como executando "MySQL" pode, na verdade, executar o MariaDB, enquanto outro pode ter o Oracle MySQL de um repositório ou contêiner separado.

mysql --version
systemctl status mysql mariadb

O primeiro comando identifica o cliente, mas não necessariamente o servidor em execução. Conecte-se usando sua conta de administrador de banco de dados e execute:

SELECT VERSION(), @@version_comment;

Utilize seu método de autenticação existente; instalações do Debian MariaDB podem permitir administração local com sudo mysql. Anote a versão do servidor e o nome real do serviço. Os comandos de serviço subsequentes usarão mysql.service; substitua mariadb.servicequando apropriado. Não adicione variáveis ​​exclusivas do Oracle à configuração do MariaDB.

2. Confirme se o desligamento foi um evento de falta de memória (OOM).

Equívoco comum: Toda reinicialização inexplicável do banco de dados é considerada uma falha por falta de memória (OOM kill). Erros de autenticação, esgotamento de disco, configurações inválidas, travamentos e reinicializações do administrador também podem interromper o serviço.

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

Procure por mensagens do kernel próximas ao horário do incidente que identifiquem uma condição de falta de memória e o processo finalizado, e correlacione essas mensagens com o log de serviço. Inspecione também o log de erros do banco de dados, caso seu pacote o grave em um arquivo em vez do journal. Se o incidente ocorreu antes de uma reinicialização, inspecione a inicialização anterior, journalctl -k -b -1quando os logs retidos estiverem disponíveis. A ausência de logs históricos impede a confirmação da causa.

Um gerenciador de espaço do usuário também pode encerrar cargas de trabalho. O manual do systemd-oomd do Debian descreve a intervenção com base na pressão de memória antes de um evento de falta de memória (OOM) do kernel. Verifique se ele está instalado e ativo, em vez de presumir que todo VPS Debian o utiliza.

Verifique também os limites do systemd:

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

Em um sistema cgroup v2, use o caminho do ControlGroup relatado para ler os valores de `<controlGroup>` memory.events, memory.max`<controlGroup>` e ` <controlGroup>` em `<controlGroup>`. Verifique também os cgroups pai. A documentação do cgroup v2 do Linux explica esses contadores e limites. Um cgroup pode ficar sem memória permitida mesmo que o host tenha capacidade disponível. Um contador registra a interrupção do processo, mas deve ser interpretado juntamente com os limites e logs para determinar a causa.memory.swap.max/sys/fs/cgroupoom_kill

3. Meça o VPS inteiro, não apenas o pool de buffers.

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

Colete observações durante o tráfego normal e as tarefas associadas a falhas. Em free, concentre-se na memória disponível, não apenas na coluna livre. O manual do Debian descreve a memória disponível como uma estimativa do que pode ser usado sem troca de memória (swap). Os valores RSS na listagem de processos estão em KiB; somá-los pode resultar em uma contagem dupla da memória compartilhada.

Verificado: O MySQL aloca memória além do buffer pool do InnoDB, incluindo alocações relacionadas a conexões e consultas. A documentação de referência sobre uso de memória do MySQL aborda esses componentes. Considere uma fórmula baseada em buffers configurados como uma estimativa de planejamento, não como um limite superior preciso.

Ação: Reserve capacidade para o kernel, web workers, monitoramento, backups e tarefas transitórias do banco de dados. A recomendação comum de dedicar a maior parte da RAM ao InnoDB não é adequada sem ajustes em um VPS compartilhado. Se os processos PHP ou uma tarefa de compilação consumirem toda a capacidade disponível, otimize ou mova essa carga de trabalho em vez de reduzir repetidamente o tamanho do MySQL.

4. Adicione a memória de swap como um buffer, não como RAM de substituição.

Dependente do contexto: a memória swap pode absorver alguma pressão temporária de memória anônima, mas o uso contínuo de swap pode tornar as consultas muito lentas. Um VPS baseado em contêineres pode restringir o uso de swap, e um serviço MemorySwapMaxpode impedir seu uso mesmo quando o host dispõe de swap.

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

Se a área de swap não estiver disponível, o provedor a permitir e você tiver espaço em disco suficiente, o comando a seguir cria um arquivo de swap de 1 GiB em um sistema de arquivos local adequado, como o ext4. Não execute este comando se o arquivo /swapfile já existir. Verifique primeiro os requisitos específicos do sistema de arquivos; o Btrfs precisa de uma configuração de arquivo de swap que não permita cópia em gravação.

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Somente após a ativação ser bem-sucedida, adicione esta entrada uma única vez a /etc/fstab:

/swapfile none swap sw 0 0

O manual do Debian swapon documenta as restrições do arquivo de swap. Se a ativação for negada pelo ambiente VPS, consulte o provedor sobre o swap suportado ou aumente a memória do plano; não persista uma configuração com falha.

Não copie a configuração "definir swappiness como zero" como proteção contra falta de memória (OOM). A documentação da VM do kernel define swappiness como uma preferência de custo de recuperação de memória. Ela não cria memória nem impõe um limite de memória ao banco de dados. Deixe-a inalterada inicialmente e observe o comportamento.

5. Defina uma base de referência modesta para o banco de dados.

Para ilustrar, considere um VPS de 1 GiB com uma pequena carga de trabalho InnoDB e alguns processos de aplicação. Os valores a seguir são candidatos para avaliação, não comprovando que essa carga de trabalho seja adequada:

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

Coloque as opções do servidor em um arquivo de configuração incluído na sua instalação. Um pacote Oracle MySQL pode incluir `/etc/mysql/options` /etc/mysql/mysql.conf.d/; o Debian MariaDB geralmente usa `/ /etc/mysql/mariadb.conf.d/etc/mysql/options`. Verifique as diretivas de inclusão existentes e faça um backup. A documentação do MySQL sobre arquivos de opções explica os grupos de opções do servidor e o gerenciamento de arquivos.

Um buffer pool de 128 MiB limita o cache, não a memória total do banco de dados. Um limite de 20 conexões pode ser muito restritivo se várias instâncias do aplicativo mantiverem um pool cada. Por outro lado, 20 consultas pesadas simultâneas ainda podem sobrecarregar o VPS. Mantenha o total de conexões do pool de aplicativos abaixo do limite pretendido do servidor, com espaço para acesso administrativo, e observe as conexões recusadas.

As variáveis ​​comuns acima também aparecem na referência de variáveis ​​de sistema do MariaDB , mas o comportamento das tabelas temporárias varia de acordo com o produto e a versão. Evite aumentar os buffers globais de classificação, junção ou leitura como uma solução genérica de desempenho em máquinas com recursos limitados.

6. Controlar tabelas temporárias e concorrência em conjunto

Equívoco comum: A configuração tmp_table_size=16Mlimita toda a memória de consulta a 16 MiB. Não limita. Múltiplas sessões, múltiplas tabelas temporárias e outras alocações de execução podem coexistir.

Para o Oracle MySQL 8.4 , um ponto de partida ilustrativo adicional é:

temptable_max_ram=64M
temptable_max_mmap=0

Adicione esses parâmetros ao [mysqld]grupo existente somente após confirmar a compatibilidade com o produto. Eles controlam o limite de RAM compartilhada do mecanismo TempTable e o uso de arquivos temporários mapeados em memória. Eles não limitam todo o processo mysqld nem todas as alocações locais de thread. Limites mais baixos podem transferir mais trabalho para o disco.

A documentação de tabelas temporárias do MySQL 8.4 explica esses limites. O MySQL 8.0 tem um comportamento dependente da versão: temptable_max_mmapo limite foi introduzido na versão 8.0.23 e tmp_table_sizetornou-se um limite individual para tabelas temporárias na versão 8.0.28. Consulte a documentação do MySQL 8.0 antes de aplicar as mesmas configurações. Não copie essas opções específicas do Oracle para o MariaDB.

Ação: Limite consultas de relatório sobrepostas, processos em segundo plano e tarefas de backup ou importação. Analise os planos de consulta e os índices quando uma operação específica gerar sobrecarga. Mover tarefas muito grandes para fora dos horários de pico de tráfego pode ajudar; se a demanda simultânea normal ainda exceder a capacidade, adicionar mais RAM ou separar o banco de dados é a próxima etapa apropriada.

7. Valide as alterações e reinicie deliberadamente.

Para versões do Oracle MySQL que suportam essa opção, verifique a configuração antes de reiniciar:

sudo mysqld --validate-config

Use o mesmo caminho do arquivo de configurações padrão e os mesmos argumentos de inicialização relevantes do serviço, caso ele não utilize a descoberta de configuração padrão. A referência de validação do MySQL observa que a validação não inicializa todos os subsistemas. Ser aprovado não é um teste de capacidade de carga de trabalho. Não assuma que o MariaDB suporte essa opção do Oracle.

Reinicie o serviço durante o período planejado e, em seguida, inspecione a inicialização e consulte os valores efetivos:

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

Variáveis ​​não suportadas não aparecerão nos resultados. Verifique as configurações pretendidas em vez de presumir que o novo arquivo teve precedência. Se a inicialização falhar devido à sua alteração, restaure a configuração salva ou remova apenas a nova substituição e reinicie. Guarde os detalhes do erro para diagnóstico.

8. Defina sucesso sob carga representativa

free -h
vmstat 1
cat /proc/pressure/memory

Compare o mesmo tráfego e tarefas agendadas antes e depois das alterações. Monitore novos eventos de falta de memória (OOM), reinicializações do banco de dados, memória disponível, recusas de conexão, atividade de swap e latência de consulta. Em casos extremos vmstat, a troca contínua de memória (swap-in/swap-out) merece investigação. O manual do vmstat do Debian explica que o primeiro relatório calcula a média da atividade desde a inicialização; use os relatórios subsequentes para obter as taxas atuais.

A referência PSI do kernel descreve as medições de bloqueio de pressão. O aumento do tempo de bloqueio de memória pode revelar problemas mesmo antes de outra interrupção. Um sistema ocioso que sobrevive por dez minutos não garante que o próximo backup ou pico de tráfego seja seguro.

Conceitos errôneos que podem agravar o problema

O manual de controle de recursos do systemd do Debian explica que MemoryMaxé possível invocar o tratamento de falta de memória (OOM) dentro de uma unidade. Não remova indiscriminadamente os limites do provedor ou do contêiner. O aplicativo precisa de um orçamento de memória que se ajuste a esses limites, ou os limites precisam de uma alteração de capacidade autorizada.

Não existe um tamanho mínimo de VPS verificado que garanta a execução dessa carga de trabalho específica. Se a taxa de transferência útil exigir troca constante de memória, se as tarefas agendadas ainda causarem interrupções ou se caches menores tornarem a latência inaceitável, pare de tratar a configuração como substituto para a capacidade. Atualize a RAM, reduza a concorrência de aplicativos ou mova o banco de dados para um serviço separado.