Rastree los errores de memoria de la actualización de SLES antes de volver a intentarlo.

Si SLES informa del error "No se puede asignar memoria" durante una actualización, primero compruebe si el kernel registró un error de falta de memoria y si se agotó la RAM o la memoria de intercambio. Pause una carga de trabajo no esencial conocida o aumente la memoria asignada a la máquina virtual solo después de confirmar la presión, y luego verifique que Zypper y RPM ya no estén activos antes de reanudar el procedimiento de actualización original.

Ejemplo hipotético: imagine una máquina virtual SLES 15 donde un administrador inicia una actualización de paquete programada mientras se ejecuta un proceso por lotes de gran tamaño. Zypper se detiene con un error de asignación de memoria. El siguiente ejemplo es ilustrativo, no un informe de un incidente o prueba real; utilice los comandos para recopilar evidencia en su propio sistema antes de elegir una solución.

1. Compruebe si el servidor aún se está actualizando.

No reinicie el sistema, no finalice los procesos de los paquetes ni ejecute un segundo comando de actualización solo porque la sesión SSH haya mostrado un error. Vuelva a conectarse en una segunda sesión y compruebe si hay procesos Zypper o RPM activos.

pgrep -a 'zypper|rpm'

Si un proceso de paquete aún está en ejecución, espere un tiempo y revise su salida o registros. No elimine los archivos de bloqueo de Zypper mientras haya una operación de paquete activa. Si no hay ningún proceso en ejecución, conserve el texto exacto del error y anote cuándo ocurrió; esta marca de tiempo ayuda a correlacionar los registros del kernel y del paquete.

2. Confirmar o descartar la presión de memoria

Recopile una instantánea actual de la RAM y del espacio de intercambio:

free -h
swapon --show
vmstat 1 5

En free -h, compruebe la availablecolumna, no solo la cantidad marcada free; Linux también usa RAM para caché. swapon --showinforma si existe intercambio y cuánto se usa. En , los valores vmstatdistintos de cero repetidos en las filas recientes indican intercambio activo; la primera fila es un promedio desde el arranque, así que concéntrese en las filas posteriores.siso

Luego, busque un error de falta de memoria del kernel (OOM) cerca del fallo y lea el registro de 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

Un registro OOM-kill que mencione RPM, Zypper u otro proceso respalda un diagnóstico genuino de presión de memoria. Una RAM "libre" baja por sí sola no es suficiente: la caché puede recuperarse y el mensaje también puede deberse a un límite de memoria de un proceso o servicio. Si no aparece ninguna entrada OOM del kernel, verifique los límites del comando que falla y cualquier límite de memoria de systemd o contenedor antes de agregar memoria del host. La causa exacta no se puede identificar solo con la frase "No se puede asignar memoria".

3. Reduzca la presión antes de volver a intentarlo.

Regrese a la máquina virtual hipotética. Si el trabajo por lotes consume memoria y el sistema muestra actividad de intercambio sostenida o un error de memoria insuficiente del kernel, utilice el procedimiento de pausa o detención compatible con la aplicación. No finalice una base de datos, una carga de trabajo SAP u otro servicio con estado sin que su operador haya realizado los pasos de apagado. Vuelva a comprobar la RAM y el intercambio después de pausar la carga de trabajo.

Si la máquina virtual sigue teniendo poca memoria durante el mantenimiento normal, aumente la RAM asignada mediante el hipervisor o el plano de control de la nube compatibles y, a continuación, confirme que el sistema operativo reconoce la nueva cantidad. Añadir memoria de intercambio puede proporcionar margen temporal, pero es más lento que la RAM y no soluciona la demanda de memoria sostenida. La configuración de almacenamiento de SLES es importante: por ejemplo, SUSE documenta restricciones específicas para los archivos de intercambio en Btrfs. Evite crear o redimensionar la memoria de intercambio durante una actualización a menos que haya comprobado los requisitos del sistema de archivos, las instantáneas y la plataforma.

Cuando no haya registros de OOM, investigue el límite que se aplica al proceso que falla. En SLES 15, inspeccione el límite de memoria configurado de una carga de trabajo administrada por systemd, reemplazando el nombre de la unidad de ejemplo con el servicio afectado:

sudo systemctl show example-batch.service -p MemoryMax

Compare ese valor con la memoria disponible. Un límite de cgroup no se solucionará aumentando la RAM de la máquina virtual a menos que también se aumente el límite adecuadamente. En los Service Packs más antiguos, confirme el nombre de la propiedad con la documentación de systemd de esa versión.

4. Reanude la misma actualización compatible y verifíquela.

Una vez finalizado el proceso del paquete, revise /var/log/zypper.logla última acción completada y cualquier paquete que haya fallado. Si RPM o Zypper informan de una transacción incompleta, siga las instrucciones de recuperación de SUSE para ese error específico antes de volver a intentarlo. No elimine manualmente los archivos de la base de datos del paquete ni los bloqueos.

Utilice la misma ruta de actualización que inició originalmente. El mantenimiento rutinario de paquetes y la migración de un Service Pack son operaciones diferentes: SUSE documenta zypper patchla instalación de los parches publicados aplicables, mientras que las actualizaciones de Service Pack y de versiones principales tienen sus propias rutas y preparaciones compatibles. No cambie a zypper dupsimplemente como una solución temporal para la memoria. Para una ejecución de parches rutinaria, revise primero la transacción:

sudo zypper patch --dry-run

Si la prueba preliminar muestra un plan razonable y la memoria es estable, programe una ventana de mantenimiento y ejecute el comando correspondiente a su tarea original. Mantenga la sesión SSH activa, supervise el proceso y verifique el 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'

Una recuperación exitosa significa que los paquetes o la migración previstos se completaron, Zypper finalizó correctamente y no se produjo ningún error de memoria insuficiente (OOM) durante la ejecución. Si el sistema arranca pero es necesario revertir la migración del Service Pack de SLES, la función de reversión de Snapper documentada por SUSE solo se aplica cuando se cumplen sus requisitos, incluyendo una raíz Btrfs compatible y la configuración de instantáneas. No considere la reversión como una respuesta genérica a un parche de paquete fallido.

Cuándo detenerse y cuándo intensificar la escalada.

Si el error se repite después de aliviar la presión de memoria, los procesos de paquetes siguen bloqueados o la base de datos RPM informa de corrupción, detenga los reintentos. Conserve el registro de Zypper, el registro del kernel, el nivel del producto y del paquete de servicio, y el comando exacto utilizado. SUSE supportconfigpuede recopilar datos de diagnóstico para un caso de soporte. Los pasos aquí descritos ayudan a distinguir la presión de memoria de otros fallos de asignación; no permiten determinar un defecto específico del producto sin los registros completos y la configuración del sistema.

Para obtener información detallada sobre SLES 15 SP7, consulte las utilidades de monitorización del sistema de SUSE , la referencia de archivos de registro , la guía de administración de Zypper , los requisitos de swap y Btrfs , y las instrucciones de actualización y reversión en línea . Los comandos y las rutas de recuperación pueden variar según el Service Pack de SLES, la arquitectura, el sistema de archivos y si la tarea consiste en aplicar parches o migrar una versión.