Identifiez les erreurs de mémoire lors de la mise à niveau de SLES avant de réessayer.

Si SLES signale « Impossible d'allouer de la mémoire » lors d'une mise à niveau, vérifiez d'abord si le noyau a enregistré une erreur de mémoire insuffisante et si la RAM ou la mémoire d'échange est saturée. Suspendez les tâches non essentielles connues ou n'augmentez la mémoire allouée à la machine virtuelle qu'après avoir confirmé la saturation, puis assurez-vous que Zypper et RPM ne sont plus actifs avant de reprendre la procédure de mise à niveau initiale.

Exemple hypothétique : imaginez une machine virtuelle SLES 15 sur laquelle un administrateur lance une mise à jour planifiée d’un package pendant l’exécution d’un traitement par lots volumineux. Zypper s’interrompt en raison d’une erreur d’allocation de mémoire. L’exemple ci-dessous est purement illustratif et ne constitue pas un rapport d’incident réel ni un test ; utilisez les commandes correspondantes pour recueillir des preuves sur votre propre système avant de choisir une solution.

1. Vérifiez si le serveur est toujours en cours de mise à niveau.

Ne redémarrez pas, n'interrompez pas les processus de paquets et ne lancez pas une seconde commande de mise à niveau simplement parce que la session SSH a affiché une erreur. Reconnectez-vous dans une seconde session et vérifiez la présence de processus Zypper ou RPM actifs.

pgrep -a 'zypper|rpm'

Si un processus de paquetage est toujours en cours d'exécution, patientez et examinez sa sortie ou ses journaux. Ne supprimez pas les fichiers de verrouillage Zypper tant qu'une opération de paquetage est susceptible d'être active. Si aucun processus n'est en cours d'exécution, conservez le texte exact de l'erreur et notez l'heure à laquelle elle s'est produite ; cet horodatage permet de corréler les journaux du noyau et du paquetage.

2. Confirmer ou infirmer la pression sur la mémoire

Collectez un instantané actuel de la RAM et du swap :

free -h
swapon --show
vmstat 1 5

Dans ` /var free -h/swap`, vérifiez la availablecolonne `/var/swap`, et pas seulement la valeur indiquéefree ; Linux utilise également la RAM pour le cache. `/var/ swapon --showswap` indique si la mémoire d'échange existe et son utilisation. Dans `/var/swap`, des valeurs vmstatnon nulles répétées dans les lignes récentes indiquent une utilisation active de la mémoire d'échange ; la première ligne correspond à une moyenne depuis le démarrage, il est donc conseillé de se concentrer sur les lignes suivantes.siso

Recherchez ensuite un arrêt du processus en raison d'une erreur de mémoire insuffisante (OOM) du noyau autour de l'incident et consultez le journal 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 enregistrement d'erreur OOM-kill mentionnant RPM, Zypper ou un autre processus confirme un diagnostic de saturation de la mémoire. Un faible niveau de RAM libre ne suffit pas : le cache peut être récupéré et le message peut également provenir d'une limite de mémoire d'un processus ou d'un service. Si aucune entrée OOM du noyau n'apparaît, vérifiez les limites de la commande ayant échoué ainsi que toute limite de mémoire systemd ou de conteneur avant d'ajouter de la mémoire hôte. La cause exacte ne peut être identifiée à partir du seul message « Impossible d'allouer de la mémoire ».

3. Réduisez la pression avant de réessayer.

Revenez à la machine virtuelle hypothétique. Si le traitement par lots consomme de la mémoire et que le système présente une activité d'échange soutenue ou une erreur de mémoire insuffisante du noyau, utilisez la procédure de pause ou d'arrêt prévue par l'application. Ne mettez pas fin à une base de données, une charge de travail SAP ou tout autre service avec état sans avoir suivi les instructions d'arrêt de son opérateur. Vérifiez à nouveau la RAM et l'espace d'échange une fois la charge de travail suspendue.

Si la machine virtuelle manque de mémoire lors d'une maintenance courante, augmentez la RAM allouée via l'hyperviseur ou le plan de contrôle cloud compatible, puis vérifiez que le système d'exploitation prend bien en compte cette nouvelle quantité. L'ajout d'espace d'échange peut fournir une marge temporaire, mais il est plus lent que la RAM et ne résout pas les problèmes de mémoire persistants. La configuration du stockage SLES est importante : par exemple, SUSE documente les contraintes spécifiques relatives aux fichiers d'échange sur Btrfs. Évitez de créer ou de redimensionner l'espace d'échange pendant une mise à niveau, sauf si vous avez vérifié au préalable la configuration requise pour le système de fichiers, les instantanés et la plateforme.

En l'absence d'enregistrements OOM, examinez la limite applicable au processus défaillant. Sous SLES 15, inspectez la limite de mémoire configurée d'une charge de travail gérée par systemd, en remplaçant le nom de l'unité d'exemple par le service concerné :

sudo systemctl show example-batch.service -p MemoryMax

Comparez cette valeur à la mémoire disponible. Augmenter la RAM de la machine virtuelle ne résoudra pas le problème de limite de cgroup, sauf si cette limite est également augmentée en conséquence. Sur les versions antérieures, vérifiez le nom de la propriété dans la documentation systemd correspondante.

4. Reprenez la même mise à niveau prise en charge et vérifiez-la.

Une fois le processus d'installation des paquets terminé, vérifiez /var/log/zypper.logla dernière action effectuée et les paquets ayant échoué. Si RPM ou Zypper signale une transaction incomplète, suivez les instructions de récupération de SUSE relatives à cette erreur avant de réessayer. Ne supprimez pas manuellement les fichiers de base de données des paquets ni les verrous.

Utilisez la même procédure de mise à niveau que celle initialement utilisée. La maintenance courante des paquets et la migration vers un Service Pack sont deux opérations distinctes : la documentation SUSE zypper patchexplique comment installer les correctifs publiés, tandis que les mises à niveau vers un Service Pack ou une version majeure suivent leurs propres procédures et nécessitent une préparation spécifique. N'optez pas pour cette zypper dupsolution comme simple palliatif. Avant d'appliquer un correctif de routine, vérifiez la procédure :

sudo zypper patch --dry-run

Si la simulation à blanc donne un résultat satisfaisant et que la mémoire est stable, planifiez une fenêtre de maintenance et exécutez la commande appropriée pour votre tâche initiale. Maintenez la session SSH ouverte, surveillez le processus et vérifiez le résultat ensuite.

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

Une récupération réussie signifie que l'installation des paquets ou la migration prévue s'est déroulée avec succès, que Zypper s'est arrêté correctement et qu'aucune erreur de mémoire insuffisante (OOM) n'est survenue pendant l'exécution. Si le système est amorçable mais qu'une migration de Service Pack SLES doit être annulée, la restauration Snapper documentée par SUSE ne s'applique que si ses conditions sont remplies, notamment un système de fichiers racine Btrfs compatible et des instantanés configurés. La restauration ne doit pas être considérée comme une solution générique à un échec d'application d'un correctif.

Quand s'arrêter et intensifier la pression

Si l'erreur persiste après la résolution du problème de mémoire, si les processus des paquets restent bloqués ou si la base de données RPM signale une corruption, cessez les tentatives de réinstallation. Conservez le journal Zypper, le journal du noyau, le niveau du produit et du Service Pack, ainsi que la commande exacte utilisée. L'équipe SUSE supportconfigpeut collecter les données de diagnostic nécessaires à l'assistance. Les étapes décrites ici permettent de distinguer les problèmes de mémoire des autres erreurs d'allocation ; elles ne permettent pas d'identifier un défaut spécifique au produit sans les journaux complets et la configuration système.

Pour plus de détails sur la version actuelle de SLES 15 SP7, consultez les utilitaires de surveillance système de SUSE , la documentation relative aux fichiers journaux , le guide d'administration de Zypper , les exigences concernant le swap et Btrfs , ainsi que les instructions de mise à niveau et de restauration en ligne . Les commandes et les procédures de récupération peuvent varier selon le Service Pack de SLES, l'architecture, le système de fichiers et selon qu'il s'agisse d'une application de correctif ou d'une migration de version.