Het probleem "Kan geen geheugen toewijzen" oplossen tijdens een SLES-systeemupgrade

De SLES-upgrade lijkt goed te verlopen, maar dan verschijnt er in een terminal, installatieprogramma of migratielogboek de melding "Kan geen geheugen toewijzen". Deze melding bewijst op zichzelf niet dat de server meer fysiek RAM-geheugen nodig heeft. De fout kan te wijten zijn aan geheugenproblemen, een limiet van de virtuele machine of service, ontbrekende of onbruikbare swapruimte, of de upgradeomgeving zelf. Stel eerst vast welk proces en welke fase van de upgrade de melding heeft veroorzaakt; de juiste oplossing hangt af van die informatie.

De versie is van belang. Vanaf oktober 2026 beschrijft de SUSE SLES 16.0-upgradehandleiding een distributiemigratiesysteem dat een speciale live-upgrade-image opstart, terwijl SLES 15-servicepackmigraties gebruikmaken van de gevestigde YaST- of Zypper-migratieworkflow. Pas geen fix die bedoeld is voor een online servicepackmigratie toe op een upgrade naar een hogere versie zonder de procedure voor uw release te raadplegen. SUSE beschrijft het huidige SLES 16-traject in de SLES 16-upgradehandleiding .

1. Identificeer de fase waarin het misgaat voordat u iets verandert.

Noteer de volledige foutmelding, het tijdstempel, de opdracht of het scherm waarop deze verscheen, en of het systeem opnieuw is opgestart met een installatieprogramma of migratie-image. "Kan geen geheugen toewijzen" is een algemene foutmelding van het besturingssysteem, dus de omringende regels zijn vaak nuttiger dan de melding zelf.

• Voordat de pakkettransactie start: mogelijk is er een fout opgetreden bij de registratie, opslag, migratievoorbereiding of installatie. Controleer het systeem- en procesgeheugen en bekijk vervolgens het relevante service- of migratielogboek.
• Tijdens het installeren of verwijderen van pakketten: Zypper en RPM hebben mogelijk al wijzigingen in het systeem aangebracht. Beëindig het proces niet, herstart de computer niet en start geen tweede pakketbeheerder, ook al lijkt de voortgang traag. Controleer de console en de logboeken en wacht tot het ondersteunde migratieproces is voltooid of een duidelijke foutmelding geeft.
• Na een herstart met een upgrade-image: het proces kan draaien met een andere resourceomgeving dan het oorspronkelijke besturingssysteem. Een swapgebied dat vóór de herstart zichtbaar was, is geen bewijs dat de upgrade-image er gebruik van kan maken.

De SUSE SLES 16-migratieprocedure bereidt de migratieomgeving voor, koppelt bestandssystemen, configureert netwerken, bereidt Zypper voor, voert upgrades uit, werkt de bootloader bij en herstart het systeem. De handleiding vermeldt dat een fout vóór de upgrade het systeem terugzet naar de oorspronkelijke staat; dit betekent echter niet dat elke fout tijdens het vervangen van pakketten onschadelijk is. Bewaar logbestanden en vermijd handmatige herstelstappen totdat u weet welke fase is mislukt.

2. Controleer het RAM-geheugen, de swapruimte en recente kernelberichten.

Als het oorspronkelijke SLES-systeem nog steeds actief is, of als u een herstelomgeving hebt bereikt, begin dan met alleen-lezen controles:

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

free -hGeeft een overzicht van het geheugen en de swap. Focus op het beschikbare geheugen en de gebruikte swap, niet alleen op de kolom 'vrij': Linux gebruikt anders ongebruikt RAM-geheugen voor caches. vmstatDit helpt om te zien of de machine continu aan het pagingen is. De proceslijst kan een database, Java-service, back-up of andere workload onthullen die geheugen verbruikt tijdens de upgrade.

Zoek naar kernel OOM-records rond het tijdstip van de fout:

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

Als de fout eerder is opgetreden, wijzig dan het tijdsvenster. Een kernelbericht met de naam van een beëindigd proces is een aanwijzing voor een geheugenprobleem; het ontbreken van een overeenkomende regel sluit niet alle toewijzingsfouten uit. Als de upgrade plaatsvindt in een aparte productieomgeving, controleer dan de logboeken van die omgeving (indien beschikbaar) in plaats van alleen te vertrouwen op het logboek van het oude systeem.

Controleer ook of een virtuele machine, container of systemd-eenheid een geheugenlimiet heeft. Een gast-VM kan weliswaar beschikbaar geheugen op de host hebben, maar toch tegen zijn eigen geconfigureerde limiet aanlopen. In SLES 16 beschrijft SUSE cgroups v2 als de standaard hiërarchie voor resourcebeheer en legt uit dat systemd resourcelimieten kan toepassen. Controleer de relevante VM-configuratie of service- MemoryMaxinstellingen in plaats van willekeurig globale kernellimieten te verhogen. Zie de SUSE SLES 16-handleiding voor kernelcontrolegroepen .

3. Verminder het gelijktijdige gebruik van geheugen en probeer het alleen opnieuw op een veilig moment.

Als uit metingen blijkt dat een workload het grootste deel van het beschikbare geheugen gebruikt, plan dan een onderhoudsvenster in en stop niet-essentiële services op een gecontroleerde manier voordat u het opnieuw probeert. Voorbeelden hiervan zijn geheugenintensieve applicatieprocessen, analysetaken, testdatabases en back-upprocessen. Stop opslag-, cluster- of applicatieservices niet zomaar op een productiehost; gebruik de gedocumenteerde afsluitprocedure van de applicatie en controleer of het stoppen ervan geen gebruikers of hersteltaken verstoort.

Vergelijk voor een virtuele machine het geconfigureerde RAM-geheugen van de gastmachine met de capaciteit van de host en de huidige geheugenbehoefte van andere gastmachines. Als de gastmachine te weinig geheugen heeft, vergroot u het toegewezen geheugen met behulp van de door de hypervisor ondersteunde methode. Of geheugen tijdens gebruik kan worden toegevoegd, hangt af van de hypervisor, de configuratie van de gastmachine en de werkbelasting; plan een herstart indien nodig. Controleer in de publieke cloud de instantiegrootte en eventuele providerspecifieke geheugenlimieten.

Als het bericht blijft verschijnen terwijl de machine voldoende RAM-geheugen heeft en er geen OOM-melding is, onderzoek dan de proceslimieten. Controleer voor een nog actief proces /proc/PID/limitsde proces-ID. Controleer voor een door systemd beheerde upgrade-helper de resource-instellingen van de unit. Een limiet kan een proces beperken, zelfs als de host voldoende geheugen heeft. Wijzig een limiet alleen als u de betreffende instelling kunt identificeren en de impact ervan begrijpt.

Nadat u de vastgestelde beperking hebt verholpen, kunt u de upgrade alleen hervatten of opnieuw proberen via de upgrademethode die wordt ondersteund voor uw specifieke SLES-release en upgradepad. Voor SLES 15-servicepackmigratie gebruikt u de gedocumenteerde YaST- of Zypper-migratieworkflow. Voor SLES 16-hoofdversiemigratie volgt u de SLES 16-distributiemigratieprocedure. De SUSE SLES 15 SP7-handleiding beschrijft de servicepackworkflow en de ondersteunde terugdraaivereisten in de online upgradedocumentatie .

4. Overweeg de swap zorgvuldig; gebruik deze niet als een blinde oplossing.

Extra swapgeheugen kan een systeem meer virtuele-geheugenruimte geven wanneer de werklast het geheugen kan pagineren, maar het is veel trager dan RAM. Als de machine al veel swapgeheugen gebruikt, kan het toevoegen van meer swapgeheugen de upgrade extreem traag maken zonder een te kleine VM of een beperking van een geïsoleerd proces op te lossen. Controleer eerst of er swapgeheugen aanwezig is en of het wordt gebruikt met swapon --showen free -h.

Gebruik de SUSE-procedure voor uw SLES-versie en bestandssysteem als u swap wilt toevoegen. Wees extra voorzichtig met Btrfs: SUSE beschrijft beperkingen voor swapbestanden op Btrfs en stelt dat er geen snapshot kan worden gemaakt zolang er een swapbestand actief is op het bronsubvolume. Aangezien SLES doorgaans afhankelijk is van Snapper-snapshots voor systeemherstel, mag u tijdens een upgradevenster geen generiek swapbestand aanmaken en activeren op het rootsubvolume waarvan een snapshot is gemaakt. Geef er de voorkeur aan om RAM toe te voegen of een correct geconfigureerde swap-partitie of ondersteunde locatie te gebruiken nadat u de opslagindeling en het herstelplan hebt gecontroleerd. De bestandssysteemspecifieke details vindt u in de SUSE SLES 15 SP7-opslaghandleiding .

Wijzig de OOM-killer niet vm.overcommit_memory, schakel deze niet uit en voer geen willekeurige opschoonopdracht uit als eerste reactie. Deze wijzigingen kunnen het symptoom maskeren, de werkbelasting destabiliseren of het herstel bemoeilijken. Verzamel eerst bewijsmateriaal en raadpleeg de specifieke richtlijnen van SUSE of uw applicatieleverancier als de logboeken wijzen op een specifieke geheugenconfiguratie.

5. Herstel als de upgrade is gestopt nadat de pakketwijzigingen zijn begonnen.

Voordat u besluit een upgrade opnieuw uit te voeren, controleert u of de pakketbeheerder nog actief is en of de migratietool een definitieve fout heeft gemeld. Als de upgrade is gestopt nadat er pakketwijzigingen waren begonnen, slaat u de volledige loguitvoer op en raadpleegt u de hersteldocumentatie voor die release. Voer de commando's zypper dup, zypper migration, YaST-migratie en RPM niet gelijktijdig uit.

In SLES 15 SP7 beschrijft SUSE de terugdraaiprocedure voor servicepacks wanneer het rootbestandssysteem Btrfs is en Snapper-snapshots zijn ingeschakeld. De terugdraaiprocedure vereist het identificeren en testen van de snapshot van vóór de migratie, waarna de terugdraaiing permanent moet worden gemaakt; het is geen universele oplossing voor elke upgradefout. De migratie van een hoofdversie in SLES 16 volgt een andere workflow, dus gebruik de huidige upgrade- en herstelinstructies in plaats van aan te nemen dat de procedure voor SLES 15 van toepassing is. Als het systeem bedrijfskritisch is, er geen geteste back-up beschikbaar is of de migratie mislukt tijdens het vervangen van pakketten, open dan een supportticket bij SUSE voordat u probeert pakketten handmatig te herstellen.

6. Controleer het systeem voordat u de normale dienstverlening hervat.

Zodra de upgrade is voltooid en de server normaal opstart, controleer dan de versie en registratie van het besturingssysteem, en vervolgens de consistentie van de pakketten en de workload die het probleem oorspronkelijk aan het licht bracht.

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

Gebruik de pakketverificatieopdracht die wordt ondersteund door uw SLES-versie; als zypper verifydeze niet beschikbaar is of zich anders gedraagt ​​in uw release, raadpleeg zypper helpdan de beheerdershandleiding van de release. Controleer de applicatie- en kernellogboeken op nieuwe fouten, bevestig dat de beoogde services gezond zijn en monitor het geheugen en de swap terwijl de belasting afneemt. Controleer of het ondersteunde upgradedoel is geïnstalleerd en of de serverregistratie en repositories zich in de verwachte status bevinden voordat u het onderhoudsvenster sluit.

Een succesvolle oplossing betekent meer dan alleen een verdwijnende foutmelding: de SLES-migratie wordt voltooid via een ondersteund pad, de machine start op met de verwachte release, pakketten en registraties worden gecontroleerd en normale workloads draaien zonder herhaalde OOM-gebeurtenissen. Als de foutmelding "Kan geen geheugen toewijzen" terugkeert ondanks een lage geheugenbelasting, voldoende swapgeheugen en geen resourcebeperking, bewaar dan de precieze log- en procesdetails. Deze aanwijzingen onderscheiden een upgradefout van een capaciteitsprobleem.