Résolution du problème « Impossible d’allouer de la mémoire » lors d’une mise à niveau du système SLES

La mise à niveau SLES semble progresser, puis un message d'erreur « Impossible d'allouer de la mémoire » s'affiche dans le terminal, le programme d'installation ou le journal de migration. Ce message ne prouve pas à lui seul que le serveur a besoin de plus de RAM physique. L'erreur peut provenir d'une saturation de la mémoire, d'une limite de machine virtuelle ou de service, d'un espace d'échange manquant ou inutilisable, ou encore de l'environnement de mise à niveau lui-même. Commencez par identifier le processus et la phase de mise à niveau qui ont généré ce message ; la solution la plus sûre dépend de ces informations.

La version est importante. À compter d'octobre 2026, le guide de mise à niveau majeure de SLES 16.0 de SUSE décrit un système de migration de distribution qui démarre une image de mise à niveau en direct dédiée, tandis que les migrations de Service Packs de SLES 15 utilisent le flux de travail de migration YaST ou Zypper établi. N'appliquez pas un correctif destiné à une migration de Service Pack en ligne à une mise à niveau majeure sans avoir vérifié la procédure de votre version. SUSE documente le chemin actuel vers SLES 16 dans son guide de mise à niveau SLES 16 .

1. Identifiez la phase défaillante avant toute modification.

Consignez l'erreur complète, l'horodatage, la commande ou l'écran où elle est apparue, et indiquez si le système a redémarré sur une image d'installation ou de migration. « Impossible d'allouer de la mémoire » est une erreur système générale ; les lignes qui l'entourent sont donc souvent plus utiles que le message seul.

• Avant le début de la transaction : une erreur peut survenir lors de l’enregistrement, de la gestion du dépôt, de la préparation de la migration ou de l’installation. Vérifiez la mémoire système et la mémoire allouée aux processus, puis consultez le journal du service ou de la migration concerné.
• Pendant l'installation ou la désinstallation de paquets : Zypper et RPM peuvent avoir modifié le système. Ne mettez pas fin au processus, ne redémarrez pas l'ordinateur et n'ouvrez pas un autre gestionnaire de paquets, même si la progression semble lente. Consultez la console et les journaux, et laissez le processus de migration se terminer ou indiquer clairement une erreur.
• Après un redémarrage sur une image de mise à niveau : le processus peut s’exécuter dans un environnement de ressources différent de celui du système d’exploitation d’origine. La présence d’une zone d’échange avant le redémarrage ne garantit pas que l’image de mise à niveau puisse l’utiliser.

La procédure de migration SLES 16 de SUSE prépare l'environnement de migration, monte les systèmes de fichiers, configure le réseau, prépare Zypper, met à jour les paquets, met à jour le chargeur de démarrage et redémarre le système. Le guide indique qu'une erreur survenant avant le début de la mise à niveau restaure le système à son état initial ; cela ne signifie pas pour autant que toute erreur lors du remplacement d'un paquet est sans conséquence. Conservez les journaux et évitez toute tentative de récupération manuelle tant que vous n'avez pas identifié l'étape défaillante.

2. Vérifiez la RAM, le swap et les messages récents du noyau

Si le système SLES d'origine est toujours en cours d'exécution, ou si vous avez accédé à un shell de récupération, commencez par des vérifications en lecture seule :

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

free -hCe récapitulatif présente la mémoire et l'espace d'échange. Il est important de se concentrer sur la mémoire disponible et l'espace d'échange utilisé, et non pas seulement sur la colonne « libre » : Linux utilise la RAM inactive pour les caches. vmstatCe récapitulatif permet de savoir si la machine effectue une pagination en continu. La liste des processus peut révéler une base de données, un service Java, une sauvegarde ou toute autre charge de travail consommant de la mémoire pendant la mise à niveau.

Recherchez les enregistrements OOM du noyau aux alentours de l'heure de l'erreur :

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

Si l'erreur s'est produite plus tôt, modifiez la plage horaire. Un message du noyau mentionnant un processus arrêté indique une erreur de mémoire insuffisante ; l'absence de ligne correspondante n'exclut pas toutes les erreurs d'allocation. Si la mise à niveau est effectuée dans un environnement de production distinct, consultez les journaux de cet environnement lorsqu'ils sont disponibles, plutôt que de vous fier uniquement au journal du système d'origine.

Vérifiez également si une machine virtuelle, un conteneur ou une unité systemd est soumise à une limite de mémoire. Une machine virtuelle invitée peut disposer de mémoire disponible sur l'hôte tout en atteignant sa propre limite configurée. Sous SLES 16, SUSE indique que cgroups v2 est la hiérarchie de contrôle des ressources par défaut et explique que systemd peut appliquer des limites de ressources. Il est recommandé de consulter la configuration de la machine virtuelle ou le paramètre du service concerné plutôt que d'augmenter les limites globales du noyau de manière aléatoire. Consultez le guide des groupes de contrôle du noyau SLES 16MemoryMax de SUSE .

3. Réduisez l'utilisation de la mémoire concurrente et ne réessayez qu'à un moment sûr.

Si les mesures indiquent qu'une charge de travail utilise la majeure partie de la mémoire disponible, planifiez une fenêtre de maintenance et arrêtez proprement les services non essentiels avant de réessayer. Il peut s'agir, par exemple, d'applications gourmandes en mémoire, de tâches d'analyse, de bases de données de test ou de processus de sauvegarde. N'arrêtez pas les services de stockage, de cluster ou d'application sans précaution sur un hôte de production ; suivez la procédure d'arrêt documentée de l'application et assurez-vous que son arrêt n'interrompra pas les utilisateurs ni une tâche de récupération.

Pour une machine virtuelle, comparez la RAM configurée avec la capacité de l'hôte et la demande actuelle des autres machines virtuelles. Si la mémoire allouée est insuffisante, augmentez-la via la méthode prise en charge par l'hyperviseur. La possibilité d'ajouter de la mémoire à chaud dépend de l'hyperviseur, de la configuration de la machine virtuelle et de la charge de travail ; prévoyez un redémarrage si nécessaire. Dans un cloud public, vérifiez la taille de l'instance et les éventuelles limites de mémoire spécifiques au fournisseur.

Si le message persiste alors que la machine dispose de suffisamment de RAM et qu'aucune erreur de mémoire insuffisante n'est signalée, examinez les limites des processus. Pour un processus en cours d'exécution, /proc/PID/limitsutilisez son ID. Pour un utilitaire de mise à niveau géré par systemd, examinez ses paramètres de ressources. Une limite peut contraindre un processus même si l'hôte dispose de mémoire libre. Ne modifiez une limite que si vous pouvez identifier le paramètre concerné et en comprendre l'impact.

Après avoir résolu la contrainte identifiée, reprenez ou réessayez uniquement via la méthode de mise à niveau prise en charge pour votre version SLES et votre chemin de mise à niveau. Pour la migration vers un Service Pack SLES 15, utilisez la procédure de migration YaST ou Zypper documentée. Pour la migration vers une version majeure SLES 16, suivez la procédure de migration de la distribution SLES 16. Le guide SUSE SLES 15 SP7 explique la procédure de migration des Service Packs et les prérequis de restauration dans la documentation de mise à niveau en ligne .

4. Réfléchissez bien avant d'effectuer cet échange ; ne l'utilisez pas comme une solution de facilité.

L'ajout d'espace d'échange (swap) peut augmenter la marge de mémoire virtuelle d'un système lorsque la charge de travail peut gérer la pagination, mais il est beaucoup plus lent que la RAM. Si la machine utilise déjà beaucoup d'espace d'échange, l'ajout d'espace supplémentaire peut considérablement ralentir la mise à niveau sans résoudre un problème de taille insuffisante de la machine virtuelle ou de limitation de processus isolé. Il convient donc de vérifier au préalable la présence d'un espace d'échange et son swapon --showutilisation free -h.

Suivez la procédure SUSE correspondant à votre version de SLES et à votre système de fichiers si vous devez ajouter de l'espace d'échange. Soyez particulièrement vigilant avec Btrfs : SUSE documente les restrictions relatives aux fichiers d'échange sur Btrfs et précise qu'il est impossible de créer un instantané lorsqu'un fichier d'échange est actif sur le sous-volume source. Étant donné que SLES utilise fréquemment les instantanés Snapper pour la restauration du système, ne créez ni n'activez un fichier d'échange générique sur le sous-volume racine de l'instantané pendant une fenêtre de mise à niveau. Privilégiez l'ajout de RAM ou l'utilisation d'une partition d'échange correctement configurée ou d'un emplacement compatible après avoir vérifié la configuration du stockage et le plan de restauration. Vous trouverez des informations détaillées spécifiques au système de fichiers dans le guide de stockage de SLES 15 SP7 .

Ne modifiez pas le comportement vm.overcommit_memorydu système, ne désactivez pas le processus de gestion de la mémoire insuffisante (OOM killer) et n'exécutez aucune commande de nettoyage arbitraire en premier lieu. Ces modifications peuvent masquer le problème, déstabiliser les charges de travail ou compliquer la récupération. Rassemblez d'abord des preuves et suivez les instructions spécifiques à votre configuration fournies par SUSE ou l'éditeur de votre application si les journaux indiquent une configuration mémoire particulière.

5. Récupérer si la mise à niveau s'est interrompue après le début des modifications du package

Avant de relancer une mise à niveau, vérifiez si le gestionnaire de paquets est toujours actif et si l'outil de migration a signalé une erreur définitive. Si la mise à niveau s'est interrompue après le début des modifications de paquets, enregistrez l'intégralité du journal et consultez la documentation de récupération spécifique à la version. N'exécutez pas simultanément les commandes `git add` zypper dup, zypper migration`yast migration` et `RPM`.

Sous SLES 15 SP7, SUSE documente la restauration du Service Pack lorsque le système de fichiers racine est Btrfs et que les snapshots Snapper sont activés. La procédure de restauration nécessite d'identifier et de tester le snapshot antérieur à la migration, puis de rendre la restauration permanente ; elle ne constitue pas une solution universelle pour toutes les erreurs de mise à niveau. La migration vers une version majeure de SLES 16 suit un processus différent ; il convient donc d'utiliser les instructions de mise à niveau et de récupération actuelles de SLES 16 plutôt que de supposer que la procédure de SLES 15 s'applique. Si le système est critique pour l'activité, ne dispose d'aucune sauvegarde testée ou si la migration échoue lors du remplacement des paquets, veuillez ouvrir un ticket auprès du support SUSE avant d'essayer une réparation manuelle des paquets.

6. Vérifiez le système avant de reprendre le service normal.

Une fois la mise à niveau terminée et le serveur redémarré normalement, vérifiez la version et l'enregistrement du système d'exploitation, puis contrôlez la cohérence des packages et la charge de travail qui a initialement révélé le problème :

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

Utilisez la commande de vérification des paquets prise en charge par votre version de SLES. Si zypper verifyelle n'est pas disponible ou se comporte différemment sur votre version, consultez zypper helple guide d'administration de cette dernière. Vérifiez les journaux d'application et du noyau pour détecter d'éventuelles nouvelles erreurs, assurez-vous que les services concernés sont opérationnels et surveillez la mémoire et l'espace d'échange pendant la reprise de la charge. Avant de fermer la fenêtre de maintenance, vérifiez que la cible de mise à niveau prise en charge a été installée et que l'enregistrement du serveur et les dépôts sont dans l'état attendu.

Une correction réussie ne se limite pas à la disparition d'un message d'erreur : la migration SLES s'achève via une méthode compatible, la machine démarre sur la version attendue, les packages et l'enregistrement sont correctement extraits et les charges de travail s'exécutent normalement sans erreurs de mémoire insuffisante répétées. Si l'erreur « Impossible d'allouer de la mémoire » persiste malgré une faible utilisation de la mémoire, un espace d'échange suffisant et l'absence de limite de ressources, conservez le journal et les détails du processus ; ces éléments permettent de distinguer un défaut de mise à niveau d'un problème de capacité.