SLES-Upgrade-Speicherfehler vor dem erneuten Versuch verfolgen

Meldet SLES während eines Upgrades „Speicher konnte nicht zugewiesen werden“, prüfen Sie zunächst, ob der Kernel einen Speichermangel festgestellt hat und ob RAM oder Swap-Speicher erschöpft sind. Unterbrechen Sie bekannte, nicht unbedingt notwendige Arbeitslasten oder erhöhen Sie den der VM zugewiesenen Speicher erst, nachdem Sie die Speicherauslastung bestätigt haben. Stellen Sie anschließend sicher, dass Zypper und RPM nicht mehr aktiv sind, bevor Sie den ursprünglichen Upgrade-Vorgang fortsetzen.

Hypothetisches Beispiel: Stellen Sie sich eine virtuelle Maschine unter SLES 15 vor, auf der ein Administrator ein geplantes Paketupdate startet, während ein umfangreicher Batch-Job ausgeführt wird. Zypper bricht mit einem Speicherzuordnungsfehler ab. Das folgende Beispiel dient der Veranschaulichung und stellt keinen Bericht über einen realen Vorfall oder Test dar. Verwenden Sie die Befehle, um auf Ihrem eigenen System Beweise zu sammeln, bevor Sie eine Lösung wählen.

1. Prüfen Sie, ob der Server noch aktualisiert wird.

Starten Sie das System nicht neu, beenden Sie keine Paketprozesse und führen Sie keinen zweiten Aktualisierungsbefehl aus, nur weil die SSH-Sitzung einen Fehler angezeigt hat. Stellen Sie eine zweite Verbindung her und prüfen Sie, ob Zypper- oder RPM-Prozesse aktiv sind.

pgrep -a 'zypper|rpm'

Läuft ein Paketierungsprozess noch, warten Sie kurz und überprüfen Sie die Ausgabe oder die Protokolle. Löschen Sie keine Zypper-Sperrdateien, solange ein Paketierungsprozess aktiv sein könnte. Läuft kein Prozess, speichern Sie den genauen Fehlertext und notieren Sie den Zeitpunkt des Auftretens; dieser Zeitstempel hilft, die Kernel- und Paketprotokolle zu korrelieren.

2. Gedächtnisdruck bestätigen oder ausschließen.

Erstellen Sie einen aktuellen RAM- und Swap-Snapshot:

free -h
swapon --show
vmstat 1 5

Überprüfen Sie in free -hder availableTabelle nicht nur den markierten Wert, sondern auch die Spalte free; Linux verwendet auch RAM für den Cache. swapon --showDie Tabelle zeigt an, ob Swap-Speicher vorhanden ist und wie viel davon genutzt wird. vmstatWiederholte Werte ungleich null siin soden letzten Zeilen deuten auf aktives Swapping hin; die erste Zeile ist ein Durchschnittswert seit dem Systemstart, daher sollten Sie sich auf die späteren Zeilen konzentrieren.

Suchen Sie anschließend nach einem Kernel-Abbruch aufgrund von Speichermangel (OOM) im Zusammenhang mit dem Fehler und lesen Sie das Zypper-Protokoll:

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

Ein OOM-Kill-Eintrag, der RPM, Zypper oder einen anderen Prozess nennt, unterstützt eine echte Diagnose von Speicherengpässen. Geringer freier Arbeitsspeicher allein reicht nicht aus: Der Cache kann freigegeben werden, und die Meldung kann auch durch ein Speicherlimit eines Prozesses oder Dienstes verursacht werden. Wenn kein OOM-Eintrag im Kernel erscheint, überprüfen Sie die Limits des fehlgeschlagenen Befehls sowie etwaige Speicherlimits von systemd oder Containern, bevor Sie Hostspeicher hinzufügen. Die genaue Ursache lässt sich nicht allein anhand der Meldung „Speicher konnte nicht zugewiesen werden“ ermitteln.

3. Reduzieren Sie den Druck, bevor Sie es erneut versuchen.

Kehren Sie zur hypothetischen VM zurück. Falls der Batch-Job viel Speicher belegt und das System anhaltende Swap-Aktivität oder einen Kernel-OOM-Kill anzeigt, verwenden Sie die von der Anwendung unterstützte Pausen- oder Stoppprozedur. Beenden Sie keine Datenbank, SAP-Workload oder andere zustandsbehaftete Dienste ohne die vom Betreiber vorgeschriebenen Herunterfahrschritte. Überprüfen Sie RAM und Swap erneut, nachdem der Workload pausiert wurde.

Sollte der Gast während der normalen Wartung weiterhin nicht genügend Arbeitsspeicher haben, erhöhen Sie den zugewiesenen RAM über den unterstützten Hypervisor oder die Cloud-Steuerungsebene und überprüfen Sie anschließend, ob das Betriebssystem die neue Speichermenge erkennt. Das Hinzufügen von Swap-Speicher kann vorübergehend zusätzlichen Speicherplatz schaffen, ist jedoch langsamer als RAM und behebt keinen dauerhaften Speicherbedarf. Das SLES-Speicherlayout ist wichtig: SUSE dokumentiert beispielsweise spezifische Einschränkungen für Swap-Dateien auf Btrfs. Vermeiden Sie das Erstellen oder Ändern der Größe von Swap-Speicher während eines Upgrades, es sei denn, Sie haben die Anforderungen an Dateisystem, Snapshot und Plattform geprüft.

Wenn keine OOM-Einträge vorhanden sind, untersuchen Sie stattdessen das Limit, das für den fehlerhaften Prozess gilt. Unter SLES 15 prüfen Sie die konfigurierte Speicherbegrenzung einer von systemd verwalteten Workload und ersetzen Sie dabei den Beispiel-Unit-Namen durch den betroffenen Dienst.

sudo systemctl show example-batch.service -p MemoryMax

Vergleichen Sie diesen Wert mit dem verfügbaren Speicher. Ein Cgroup-Limit lässt sich nicht durch Erhöhen des RAM der VM beheben, es sei denn, das Limit wird entsprechend angepasst. Überprüfen Sie bei älteren Service Packs den Eigenschaftsnamen anhand der systemd-Dokumentation der jeweiligen Version.

4. Setzen Sie das gleiche unterstützte Upgrade fort und überprüfen Sie es.

Sobald der Paketierungsprozess beendet ist, überprüfen Sie /var/log/zypper.logdie zuletzt abgeschlossene Aktion und eventuell fehlgeschlagene Pakete. Falls RPM oder Zypper eine unvollständige Transaktion meldet, befolgen Sie die SUSE-Anleitung zur Fehlerbehebung für genau diesen Fehler, bevor Sie es erneut versuchen. Entfernen Sie keine Paketdatenbankdateien oder Sperren manuell.

Verwenden Sie denselben Upgrade-Pfad, den Sie ursprünglich eingeschlagen haben. Routinemäßige Paketwartung und eine Service-Pack-Migration sind unterschiedliche Vorgänge: SUSE dokumentiert zypper patchdie Installation der entsprechenden veröffentlichten Patches, während Service-Pack- und Hauptversions-Upgrades ihre eigenen unterstützten Pfade und Vorbereitungen erfordern. Wechseln Sie nicht zypper dupeinfach nur aus Gründen der Speicheroptimierung. Überprüfen Sie vor der Ausführung eines routinemäßigen Patches die Transaktion.

sudo zypper patch --dry-run

Wenn der Testlauf einen plausiblen Ablauf zeigt und die Speicherauslastung stabil ist, planen Sie ein Wartungsfenster ein und führen Sie den entsprechenden Befehl für Ihre ursprüngliche Aufgabe aus. Halten Sie die SSH-Sitzung aktiv, überwachen Sie den Prozess und überprüfen Sie anschließend das Ergebnis.

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

Eine erfolgreiche Wiederherstellung bedeutet, dass die vorgesehenen Pakete oder die Migration abgeschlossen wurden, Zypper ordnungsgemäß beendet wurde und während des Laufs kein neuer Speichermangel (OOM) aufgetreten ist. Wenn das System bootfähig ist, aber eine SLES-Service-Pack-Migration rückgängig gemacht werden muss, ist das von SUSE dokumentierte Snapper-Rollback nur anwendbar, wenn die Voraussetzungen erfüllt sind, einschließlich eines unterstützten Btrfs-Root-Verzeichnisses und konfigurierter Snapshots. Behandeln Sie ein Rollback nicht als allgemeine Reaktion auf einen fehlgeschlagenen Paketpatch.

Wann man aufhören und wann man eskalieren sollte

Wenn der Fehler nach Behebung des Speicherengpasses weiterhin auftritt, Paketprozesse weiterhin hängen bleiben oder die RPM-Datenbank Beschädigungen meldet, brechen Sie die Wiederholungsversuche ab. Bewahren Sie das Zypper-Protokoll, das Kernel-Journal, die Produkt- und Service-Pack-Ebene sowie den exakt verwendeten Befehl auf. SUSE supportconfigkann Diagnosedaten für einen Supportfall sammeln. Die hier beschriebenen Schritte helfen, Speicherengpässe von anderen Speicherzuweisungsfehlern zu unterscheiden; ohne die vollständigen Protokolle und die Systemkonfiguration können sie jedoch keinen produktspezifischen Fehler feststellen.

Aktuelle Details zu SLES 15 SP7 finden Sie in den Systemüberwachungs-Tools von SUSE , der Protokolldatei-Referenz , der Zypper-Administrationsanleitung , den Anforderungen an Swap und Btrfs sowie den Anweisungen für Online-Upgrades und Rollbacks . Befehle und Wiederherstellungspfade können je nach SLES-Service-Pack, Architektur, Dateisystem und Art der Aufgabe (Patching oder Release-Migration) variieren.