Corrigir o erro “Não é possível alocar memória” durante uma atualização do sistema SLES.

A atualização do SLES parece estar progredindo, mas então um terminal, instalador ou log de migração reporta a mensagem “Não é possível alocar memória”. Essa mensagem, por si só, não comprova que o servidor precisa de mais RAM física. A falha pode ser causada por pressão de memória, limite de máquina virtual ou serviço, swap ausente ou inutilizável, ou pelo próprio ambiente de atualização. Primeiro, identifique qual processo e fase da atualização geraram a mensagem; a solução segura depende desse detalhe.

A versão é importante. Em outubro de 2026, o guia de atualização de versão principal do SLES 16.0 da SUSE descreve um sistema de migração de distribuição que inicializa uma imagem de atualização dedicada, enquanto as migrações de service pack do SLES 15 usam o fluxo de trabalho de migração estabelecido do YaST ou Zypper. Não aplique uma correção destinada a uma migração online de service pack a uma atualização de versão principal sem verificar o procedimento da sua versão. A SUSE documenta o caminho atual do SLES 16 em seu guia de atualização do SLES 16 .

1. Identifique a fase problemática antes de fazer qualquer alteração.

Registre o erro completo, o carimbo de data/hora, o comando ou a tela em que ele apareceu e se o sistema foi reiniciado em um instalador ou imagem de migração. "Não é possível alocar memória" é um erro genérico do sistema operacional, portanto, as linhas adjacentes costumam ser mais úteis do que a mensagem sozinha.

• Antes do início da transação do pacote: um processo de registro, repositório, preparação de migração ou instalação pode estar falhando. Verifique a memória do sistema e dos processos e, em seguida, revise o log de serviço ou migração relevante.
• Enquanto pacotes estão sendo instalados ou removidos: Zypper e RPM podem já ter alterado o sistema. Não encerre o processo, reinicie o computador ou inicie um segundo gerenciador de pacotes apenas porque o progresso parece lento. Verifique o console e os logs e permita que o processo de migração suportado seja concluído ou chegue a um estado de falha claro.
• Após uma reinicialização para uma imagem de atualização: o processo pode estar sendo executado com um ambiente de recursos diferente do sistema operacional original. Uma área de swap visível antes da reinicialização não comprova que a imagem de atualização possa utilizá-la.

A sequência de migração do SLES 16 da SUSE prepara o ambiente de migração, monta os sistemas de arquivos, configura a rede, prepara o Zypper, atualiza os pacotes, atualiza o carregador de inicialização e reinicia o sistema. O guia afirma que um erro antes do início da atualização reverte o sistema ao seu estado original; isso não significa que todo erro durante a substituição de pacotes seja inofensivo. Preserve os logs e evite etapas de recuperação manual até que você saiba qual etapa falhou.

2. Verifique a RAM, a memória de troca (swap) e as mensagens recentes do kernel.

Se o sistema SLES original ainda estiver em execução ou se você tiver alcançado um shell de recuperação, comece com verificações somente leitura:

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

free -hResume a memória e o swap. Concentre-se na memória disponível e no swap utilizado, não apenas na coluna "livre": o Linux usa a RAM ociosa para caches. vmstatAjuda a mostrar se a máquina está paginando continuamente. A lista de processos pode revelar um banco de dados, serviço Java, backup ou outra carga de trabalho consumindo memória durante a atualização.

Procure por registros de falta de memória (OOM) do kernel próximos ao horário do erro:

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

Se o erro ocorreu antes, altere o intervalo de tempo. Uma mensagem do kernel que menciona um processo finalizado é evidência de um evento de falta de memória; a ausência de uma linha correspondente não descarta todas as falhas de alocação. Se a atualização for realizada em um ambiente de produção separado, inspecione os logs desse ambiente, quando disponíveis, em vez de confiar apenas no registro de eventos do sistema antigo.

Verifique também se uma máquina virtual, contêiner ou unidade systemd possui um limite de memória. Um convidado pode ter memória disponível no host, mas ainda assim atingir seu próprio limite configurado. No SLES 16, a SUSE documenta os cgroups v2 como a hierarquia de controle de recursos padrão e explica que o systemd pode aplicar limites de recursos. Revise a configuração relevante da VM ou do serviço MemoryMaxem vez de aumentar os limites globais do kernel aleatoriamente. Consulte o guia de grupos de controle do kernel do SLES 16 da SUSE .

3. Reduza o uso de memória concorrente e tente novamente apenas em um ponto seguro.

Se as medições mostrarem que uma carga de trabalho está utilizando a maior parte da memória disponível, agende uma janela de manutenção e interrompa os serviços não essenciais de forma adequada antes de tentar novamente. Exemplos incluem processos de aplicação que consomem muita memória, tarefas de análise, bancos de dados de teste e processos de backup. Não interrompa serviços de armazenamento, cluster ou aplicação indiscriminadamente em um host de produção; utilize o procedimento de desligamento documentado da aplicação e confirme se a interrupção não afetará os usuários ou uma tarefa de recuperação.

Para uma máquina virtual, compare a RAM configurada do convidado com a capacidade do host e a demanda atual de outros convidados. Se o convidado estiver com recursos insuficientes, aumente a memória alocada usando o método suportado pelo hipervisor. A possibilidade de adicionar memória a quente depende do hipervisor, da configuração do convidado e da carga de trabalho; planeje uma reinicialização, se necessário. Em nuvem pública, verifique o tamanho da instância e quaisquer limites de memória específicos do provedor.

Se a mensagem persistir mesmo com a máquina tendo RAM disponível em abundância e nenhum registro de falta de memória (OOM), investigue os limites do processo. Para um processo ainda em execução, inspecione-o /proc/PID/limitsusando seu ID de processo real. Para um auxiliar de atualização gerenciado pelo systemd, inspecione as configurações de recursos da unidade. Um limite pode restringir um processo mesmo quando o host tem memória livre. Altere um limite somente se você puder identificar a configuração aplicável e entender seu impacto.

Após resolver a restrição identificada, retome ou tente novamente apenas pelo método de atualização compatível com sua versão e caminho de atualização específicos do SLES. Para migração de service packs do SLES 15, use o fluxo de trabalho de migração documentado do YaST ou Zypper. Para migração de versão principal do SLES 16, siga o procedimento de migração de distribuição do SLES 16. O guia do SLES 15 SP7 da SUSE explica o fluxo de trabalho de service packs e os pré-requisitos de reversão compatíveis na documentação de atualização online .

4. Considere a troca com cuidado; não a utilize como uma solução às cegas.

A adição de swap pode fornecer ao sistema mais espaço de memória virtual quando a carga de trabalho pode paginar a memória, mas é muito mais lenta que a RAM. Se a máquina já estiver usando swap intensivamente, adicionar mais swap pode tornar a atualização extremamente lenta sem resolver problemas como VMs subdimensionadas ou limitações de processos isolados. Primeiro, verifique se o swap existe e se está sendo usado swapon --showcorretamente free -h.

Se precisar adicionar swap, siga o procedimento da SUSE para sua versão do SLES e sistema de arquivos. Tenha cuidado especial com o Btrfs: a SUSE documenta as restrições para arquivos de swap no Btrfs e afirma que um snapshot não pode ser criado enquanto um arquivo de swap no subvolume de origem estiver ativo. Como o SLES geralmente depende de snapshots do Snapper para recuperação do sistema, não crie e ative um arquivo de swap genérico no subvolume raiz do snapshot durante uma janela de atualização. Prefira adicionar RAM ou usar uma partição de swap configurada corretamente ou um local compatível após verificar o layout de armazenamento e o plano de recuperação. Os detalhes específicos do sistema de arquivos estão no guia de armazenamento do SLES 15 SP7 da SUSE .

Não altere vm.overcommit_memory, desative o OOM killer nem execute um comando de limpeza arbitrário como primeira resposta. Essas alterações podem mascarar o sintoma, desestabilizar cargas de trabalho ou dificultar a recuperação. Reúna evidências primeiro e siga as orientações específicas da SUSE ou do fornecedor do seu aplicativo se os registros apontarem para uma configuração de memória especializada.

5. Recuperar caso a atualização tenha sido interrompida após o início das alterações do pacote.

Antes de decidir executar uma atualização novamente, verifique se o gerenciador de pacotes ainda está ativo e se a ferramenta de migração relatou uma falha final. Se a atualização foi interrompida após o início das alterações de pacotes, salve o log completo e consulte a documentação de recuperação específica da versão. Não execute os comandos zypper dup` zypper migrationyast migrate`, `yast migration` e `RPM` simultaneamente.

No SLES 15 SP7, a SUSE documenta o procedimento de reversão de service pack quando o sistema de arquivos raiz é Btrfs e os snapshots do Snapper estão habilitados. O procedimento de reversão exige a identificação e o teste do snapshot pré-migração, e então a transformação da reversão em permanente; não é uma solução universal para todos os erros de atualização. A migração de versão principal do SLES 16 segue um fluxo de trabalho diferente, portanto, utilize as instruções de atualização e recuperação atuais, em vez de presumir que o procedimento do SLES 15 se aplica. Se o sistema for crítico para os negócios, não houver um backup testado ou se a migração falhar durante a substituição de pacotes, abra um chamado de suporte da SUSE antes de tentar reparos manuais de pacotes.

6. Verifique o sistema antes de retomar o serviço normal.

Após a conclusão da atualização e a inicialização normal do servidor, verifique a versão e o registro do sistema operacional e, em seguida, verifique a consistência dos pacotes e a carga de trabalho que originalmente expôs o problema:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

Use o comando de verificação de pacotes compatível com a sua versão do SLES; se zypper verifyele não estiver disponível ou se comportar de maneira diferente na sua versão, consulte zypper helpo guia de administração da versão. Verifique os logs de aplicativos e do kernel em busca de novos erros, confirme se os serviços pretendidos estão íntegros e monitore a memória e o swap enquanto a carga retorna. Verifique se o destino de atualização compatível foi instalado e se o registro e os repositórios do servidor estão no estado esperado antes de fechar a janela de manutenção.

Uma correção bem-sucedida significa mais do que o desaparecimento de uma mensagem de erro: a migração do SLES é concluída usando um caminho compatível, a máquina inicializa na versão esperada, os pacotes e registros são verificados e as cargas de trabalho normais são executadas sem eventos repetidos de falta de memória (OOM). Se a mensagem "Não é possível alocar memória" retornar apesar da baixa pressão de memória, swap adequado e nenhum limite de recursos, guarde o log preciso e os detalhes do processo — essas pistas distinguem um defeito de atualização de um problema de capacidade.