Solucionar el error "No se puede asignar memoria" durante una actualización del sistema SLES

La actualización de SLES parece estar progresando, pero luego aparece el mensaje "No se puede asignar memoria" en la terminal, el instalador o el registro de migración. Este mensaje no demuestra por sí solo que el servidor necesite más RAM física. El fallo podría deberse a la falta de memoria, a un límite de la máquina virtual o del servicio, a la ausencia o inutilización de la memoria de intercambio, o al propio entorno de actualización. Primero, identifique qué proceso y fase de la actualización generaron el mensaje; la solución adecuada depende de este detalle.

La versión importa. A partir de octubre de 2026, la guía de actualización de la versión principal SLES 16.0 de SUSE describe un sistema de migración de distribución que arranca una imagen de actualización en vivo dedicada, mientras que las migraciones de paquetes de servicio de SLES 15 utilizan el flujo de trabajo de migración establecido de YaST o Zypper. No aplique una corrección destinada a una migración de paquete de servicio en línea a una actualización de versión principal sin consultar el procedimiento de su versión. SUSE documenta la ruta actual de SLES 16 en su guía de actualización de SLES 16 .

1. Identifique la fase que está fallando antes de cambiar nada.

Registre el error completo, la marca de tiempo, el comando o la pantalla donde apareció, y si el sistema se reinició con una imagen de instalación o migración. El error "No se puede asignar memoria" es un error general del sistema operativo, por lo que las líneas que lo rodean suelen ser más útiles que el mensaje en sí.

• Antes de que comience la transacción del paquete: es posible que falle algún proceso de registro, repositorio, preparación de la migración o instalación. Verifique la memoria del sistema y del proceso, y luego revise el registro de servicio o de migración correspondiente.
• Mientras se instalan o desinstalan paquetes, es posible que Zypper y RPM ya hayan modificado el sistema. No interrumpa el proceso, no reinicie el equipo ni inicie otro gestor de paquetes solo porque el progreso parezca lento. Revise la consola y los registros, y permita que el proceso de migración compatible finalice o muestre un error claro.
• Tras reiniciar el sistema con una imagen de actualización, es posible que el proceso se ejecute con un entorno de recursos diferente al del sistema operativo original. El hecho de que el área de intercambio sea visible antes del reinicio no garantiza que la imagen de actualización pueda utilizarla.

La secuencia de migración de SUSE SLES 16 prepara el entorno de migración, monta los sistemas de archivos, configura la red, prepara Zypper, actualiza los paquetes, actualiza el gestor de arranque y reinicia el sistema. La guía indica que un error antes de que comience la actualización revierte el sistema a su estado original; esto no significa que todos los errores durante el reemplazo de paquetes sean inofensivos. Conserve los registros y evite los pasos de recuperación manual hasta que sepa qué etapa falló.

2. Compruebe la RAM, el espacio de intercambio y los mensajes recientes del kernel.

Si el sistema SLES original todavía está en funcionamiento o si ha accedido a una consola de recuperación, comience con comprobaciones de solo lectura:

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

free -hResume la memoria y el intercambio. Concéntrese en la memoria disponible y el intercambio utilizado, no solo en la columna "libre": Linux utiliza RAM que de otro modo estaría inactiva para las cachés. vmstatAyuda a mostrar si la máquina está paginando continuamente. La lista de procesos puede revelar una base de datos, un servicio Java, una copia de seguridad u otra carga de trabajo que consume memoria durante la actualización.

Busque registros OOM del kernel en torno al momento del error:

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

Si el error ocurrió antes, modifique el intervalo de tiempo. Un mensaje del kernel que mencione un proceso finalizado indica un error de memoria insuficiente; la ausencia de una línea coincidente no descarta todos los fallos de asignación. Si la actualización se realiza en un entorno de producción independiente, revise los registros de dicho entorno cuando estén disponibles, en lugar de basarse únicamente en el registro del sistema anterior.

Compruebe también si una máquina virtual, contenedor o unidad systemd tiene un límite de memoria. Un sistema invitado puede tener memoria disponible en el host, pero aun así alcanzar su propio límite configurado. En SLES 16, SUSE documenta cgroups v2 como la jerarquía de control de recursos predeterminada y explica que systemd puede aplicar límites de recursos. Revise la configuración de la máquina virtual o del servicio correspondiente en lugar de aumentar los límites globales del kernel de forma aleatoria. Consulte la guía de grupos de control del kernel de SLES 16MemoryMax de SUSE .

3. Reduzca el uso simultáneo de memoria y vuelva a intentarlo solo en un punto seguro.

Si las mediciones indican que una carga de trabajo está utilizando la mayor parte de la memoria disponible, programe una ventana de mantenimiento y detenga correctamente los servicios no esenciales antes de volver a intentarlo. Algunos ejemplos son los procesos de aplicaciones que consumen mucha memoria, las tareas de análisis, las bases de datos de prueba y los procesos de copia de seguridad. No detenga indiscriminadamente los servicios de almacenamiento, clúster o aplicación en un servidor de producción; utilice el procedimiento de apagado documentado de la aplicación y confirme que su detención no interrumpirá a los usuarios ni una tarea de recuperación.

Para una máquina virtual, compare la RAM configurada del invitado con la capacidad del host y la demanda actual de otros invitados. Si el invitado tiene memoria insuficiente, aumente la memoria asignada mediante el método compatible con el hipervisor. La posibilidad de agregar memoria en caliente depende del hipervisor, la configuración del invitado y la carga de trabajo; planifique un reinicio si es necesario. En la nube pública, verifique el tamaño de la instancia y cualquier límite de memoria específico del proveedor.

Si el mensaje persiste a pesar de que la máquina dispone de suficiente RAM y no hay registros de errores de memoria insuficiente (OOM), investigue los límites de los procesos. Para un proceso que aún se esté ejecutando, verifique /proc/PID/limitssu ID de proceso. Para un asistente de actualización administrado por systemd, revise la configuración de recursos de la unidad. Un límite puede restringir un proceso incluso cuando el host tiene memoria libre. Modifique un límite solo si puede identificar la configuración correspondiente y comprender su impacto.

Tras solucionar la restricción identificada, reanude o vuelva a intentarlo únicamente mediante el método de actualización compatible con su versión y ruta de actualización específicas de SLES. Para la migración de Service Pack de SLES 15, utilice el flujo de trabajo de migración documentado de YaST o Zypper. Para la migración de versión principal de SLES 16, siga el procedimiento de migración de distribución de SLES 16. La guía de SUSE para SLES 15 SP7 explica su flujo de trabajo de Service Pack y los requisitos previos de reversión compatibles en la documentación de actualización en línea .

4. Considere el intercambio con detenimiento; no lo utilice como una solución a ciegas.

El intercambio adicional puede proporcionar a un sistema más margen de memoria virtual cuando la carga de trabajo puede paginar la memoria, pero es mucho más lento que la RAM. Si la máquina ya está utilizando mucho el intercambio, añadir más intercambio puede hacer que la actualización sea extremadamente lenta sin resolver una máquina virtual de tamaño insuficiente o un límite de proceso aislado. Primero, confirme si existe intercambio y si se está utilizando con swapon --showy free -h.

Si necesita agregar espacio de intercambio, siga el procedimiento de SUSE para su versión de SLES y sistema de archivos. Tenga especial cuidado con Btrfs: SUSE documenta las restricciones para los archivos de intercambio en Btrfs e indica que no se puede crear una instantánea mientras un archivo de intercambio en el subvolumen de origen esté activo. Dado que SLES suele depender de las instantáneas de Snapper para la recuperación del sistema, no cree ni active un archivo de intercambio genérico en el subvolumen raíz de la instantánea durante una ventana de actualización. Es preferible agregar RAM o usar una partición de intercambio configurada correctamente o una ubicación compatible después de verificar la distribución del almacenamiento y el plan de recuperación. Los detalles específicos del sistema de archivos se encuentran en la guía de almacenamiento de SLES 15 SP7 de SUSE .

No modifique la configuración vm.overcommit_memory, desactive el mecanismo de eliminación de memoria (OOM killer) ni ejecute comandos de limpieza arbitrarios como primera medida. Estos cambios pueden ocultar el problema, desestabilizar las cargas de trabajo o dificultar la recuperación. Recopile primero la información relevante y, si los registros indican una configuración de memoria específica, consulte las instrucciones de SUSE o del proveedor de su aplicación.

5. Recuperar si la actualización se detuvo después de que comenzaron los cambios en el paquete.

Antes de decidir volver a ejecutar una actualización, compruebe si el gestor de paquetes sigue activo y si la herramienta de migración ha informado de un fallo definitivo. Si la actualización se detuvo después de que comenzaran los cambios en los paquetes, guarde el registro completo y consulte la documentación de recuperación específica de la versión. No ejecute los comandos zypper dup, zypper migration, de migración de YaST ni de RPM simultáneamente.

En SLES 15 SP7, SUSE documenta la reversión del Service Pack cuando el sistema de archivos raíz es Btrfs y las instantáneas de Snapper están habilitadas. El procedimiento de reversión requiere identificar y probar la instantánea previa a la migración, y luego hacer la reversión permanente; no es una solución universal para todos los errores de actualización. La migración de versión principal de SLES 16 sigue un flujo de trabajo diferente, por lo que utilice sus instrucciones de actualización y recuperación actuales en lugar de asumir que se aplica el procedimiento de SLES 15. Si el sistema es crítico para el negocio, no tiene una copia de seguridad probada o la migración falla durante el reemplazo del paquete, abra un caso de soporte de SUSE antes de intentar reparaciones manuales de paquetes.

6. Verifique el sistema antes de reanudar el servicio normal.

Una vez que la actualización se haya completado y el servidor arranque normalmente, verifique la versión y el registro del sistema operativo, y luego compruebe la coherencia del paquete y la carga de trabajo que originalmente expuso el problema:

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

Utilice el comando package-verification compatible con su versión de SLES; si zypper verifyno está disponible o se comporta de manera diferente en su versión, consulte zypper helpla guía de administración de la versión. Revise los registros de la aplicación y del kernel en busca de nuevos errores, confirme que los servicios previstos funcionan correctamente y supervise la memoria y el intercambio mientras se restablece la carga. Verifique que el destino de actualización compatible se haya instalado y que el registro y los repositorios del servidor se encuentren en el estado esperado antes de cerrar la ventana de mantenimiento.

Una solución exitosa implica más que la desaparición del mensaje de error: la migración a SLES se completa mediante una ruta compatible, la máquina arranca con la versión esperada, los paquetes y el registro se verifican correctamente y las cargas de trabajo normales se ejecutan sin eventos de falta de memoria repetidos. Si el mensaje "No se puede asignar memoria" persiste a pesar de la baja presión de memoria, un espacio de intercambio adecuado y la ausencia de límite de recursos, conserve el registro preciso y los detalles del proceso; estas pistas permiten distinguir un defecto de actualización de un problema de capacidad.