Rastrear erros de memória na atualização do SLES antes de tentar novamente

Se o SLES reportar “Não é possível alocar memória” durante uma atualização, verifique primeiro se o kernel registrou um evento de falta de memória e se a RAM ou a memória de troca foram esgotadas. Pause uma carga de trabalho não essencial conhecida ou aumente a memória alocada para a VM somente após confirmar a pressão, e então verifique se o Zypper e o RPM não estão mais ativos antes de retomar o procedimento de atualização original.

Exemplo hipotético: imagine uma máquina virtual SLES 15 onde um administrador inicia uma atualização de pacote agendada enquanto um grande job em lote está em execução. O Zypper para com um erro de alocação de memória. O exemplo abaixo é ilustrativo, não um relato de um incidente ou teste real; use os comandos para coletar evidências em seu próprio host antes de escolher uma solução.

1. Verifique se o servidor ainda está sendo atualizado.

Não reinicie o sistema, encerre processos de pacotes ou execute um segundo comando de atualização apenas porque a sessão SSH exibiu um erro. Reconecte-se em uma segunda sessão e verifique se há processos Zypper ou RPM ativos:

pgrep -a 'zypper|rpm'

Se um processo de pacote ainda estiver em execução, aguarde um pouco e inspecione sua saída ou registros. Não exclua arquivos de bloqueio Zypper enquanto uma operação de pacote estiver ativa. Se nenhum processo estiver em execução, preserve o texto exato do erro e anote quando ele ocorreu; esse registro de data e hora ajuda a correlacionar os registros do kernel e do pacote.

2. Confirme ou descarte a pressão sobre a memória.

Obtenha um snapshot atual da RAM e da área de swap:

free -h
swapon --show
vmstat 1 5

Em ` free -h/etc/swap`, verifique a availablecoluna `swap`, não apenas a quantidade marcada como `true` free; o Linux também usa RAM para cache. `/etc/swap` swapon --showinforma se a memória swap existe e quanto está sendo usado. Em `/etc/swap`, valores diferentes vmstatde zero repetidos nas linhas recentes indicam swap ativo; a primeira linha é uma média desde a inicialização, portanto, concentre-se nas linhas posteriores.siso

Em seguida, procure por uma interrupção do kernel por falta de memória (OOM) próxima ao momento da falha e leia o log do Zypper:

sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
sudo tail -n 80 /var/log/zypper.log

Um registro OOM-kill que mencione RPM, Zypper ou outro processo corrobora um diagnóstico genuíno de pressão de memória. Pouca RAM "livre" por si só não é suficiente: o cache pode ser recuperado e a mensagem também pode resultar de um limite de memória de um processo ou serviço. Se nenhuma entrada OOM do kernel for exibida, verifique os limites do comando com falha e quaisquer limites de memória do systemd ou do contêiner antes de adicionar memória ao host. A causa exata não pode ser identificada apenas pela frase "Não foi possível alocar memória".

3. Reduza a pressão antes de tentar novamente.

Retorne à VM hipotética. Se o job em lote estiver consumindo memória e o sistema apresentar atividade contínua de swap ou um erro de falta de memória (OOM kill) do kernel, utilize o procedimento de pausa ou parada suportado pelo aplicativo. Não encerre um banco de dados, uma carga de trabalho SAP ou outro serviço com estado sem as etapas de desligamento definidas pelo operador. Verifique a RAM e o swap novamente após a pausa da carga de trabalho.

Se a máquina virtual continuar com pouca memória durante a manutenção normal, aumente a RAM alocada por meio do hipervisor ou plano de controle da nuvem compatível e confirme se o sistema operacional reconhece a nova quantidade. Adicionar swap pode fornecer espaço temporário, mas é mais lento que a RAM e não resolve a demanda contínua de memória. O layout de armazenamento do SLES é importante: por exemplo, a SUSE documenta restrições específicas para arquivos de swap no Btrfs. Evite criar ou redimensionar arquivos de swap durante uma atualização, a menos que você tenha verificado os requisitos do sistema de arquivos, snapshots e plataforma.

Quando não houver registros de OOM (falta de memória), investigue o limite que se aplica ao processo com falha. No SLES 15, inspecione o limite de memória configurado de uma carga de trabalho gerenciada pelo systemd, substituindo o nome da unidade de exemplo pelo serviço afetado:

sudo systemctl show example-batch.service -p MemoryMax

Compare esse valor com a memória disponível. Um limite de cgroup não será corrigido aumentando a RAM da VM, a menos que o limite também seja aumentado adequadamente. Em service packs mais antigos, confirme o nome da propriedade na documentação do systemd daquela versão.

4. Retome a mesma atualização compatível e verifique-a.

Após a conclusão do processo de empacotamento, verifique /var/log/zypper.loga última ação concluída e se houve falha em algum pacote. Se o RPM ou o Zypper reportarem uma transação incompleta, siga as orientações de recuperação da SUSE para esse erro específico antes de tentar novamente. Não remova manualmente arquivos ou bloqueios do banco de dados do pacote.

Use o mesmo caminho de atualização que você iniciou originalmente. A manutenção rotineira de pacotes e a migração de um Service Pack são operações diferentes: a SUSE documenta zypper patcha instalação de patches aplicáveis, enquanto as atualizações de Service Pack e de versões principais têm seus próprios caminhos e preparativos. Não mude para essa opção zypper dupsimplesmente como uma solução alternativa para economizar memória. Para uma aplicação rotineira de patch, revise a transação primeiro:

sudo zypper patch --dry-run

Se o teste preliminar mostrar um plano razoável e a memória estiver estável, agende uma janela de manutenção e execute o comando apropriado para sua tarefa original. Mantenha a sessão SSH aberta, monitore o processo e verifique o resultado posteriormente.

sudo tail -n 80 /var/log/zypper.log
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'

Uma recuperação bem-sucedida significa que os pacotes ou a migração pretendida foram concluídos, o Zypper foi encerrado corretamente e nenhum novo evento de falta de memória (OOM) ocorreu durante a execução. Se o sistema for inicializável, mas uma migração de service pack do SLES precisar ser revertida, o rollback do Snapper documentado pela SUSE se aplica somente quando seus requisitos forem atendidos, incluindo um sistema de arquivos raiz Btrfs compatível e snapshots configurados. Não considere o rollback como uma resposta genérica a uma falha na aplicação de um patch de pacote.

Quando parar e intensificar o processo.

Se o erro persistir mesmo após a redução da pressão na memória, os processos do pacote continuarem travados ou o banco de dados RPM reportar corrupção, interrompa as tentativas. Preserve o log do Zypper, o journal do kernel, o nível do produto e do service pack, e o comando exato utilizado. A SUSE supportconfigpode coletar dados de diagnóstico para um chamado de suporte. Os passos descritos aqui ajudam a distinguir a pressão na memória de outras falhas de alocação; eles não conseguem determinar um defeito específico do produto sem os logs completos e a configuração do sistema.

Para obter detalhes atualizados sobre o SLES 15 SP7, consulte os utilitários de monitoramento de sistema da SUSE , a referência de arquivos de log , as orientações de administração do Zypper , os requisitos de swap e Btrfs e as instruções de atualização e reversão online . Os comandos e os caminhos de recuperação podem variar de acordo com o service pack do SLES, a arquitetura, o sistema de arquivos e se a tarefa é de aplicação de patch ou migração de versão.