Traceer geheugenfouten tijdens de SLES-upgrade voordat u het opnieuw probeert.

Als SLES tijdens een upgrade de melding "Kan geen geheugen toewijzen" geeft, controleer dan eerst of de kernel een geheugenprobleem heeft geregistreerd en of het RAM-geheugen of de swapruimte is uitgeput. Pauzeer een bekende, niet-essentiële workload of verhoog het toegewezen geheugen van de VM pas nadat u de druk op het geheugen hebt gecontroleerd. Controleer vervolgens of Zypper en RPM niet langer actief zijn voordat u de oorspronkelijke upgradeprocedure hervat.

Hypothetisch voorbeeld: stel je een virtuele machine met SLES 15 voor, waar een beheerder een geplande pakketupdate start terwijl een grote batchtaak wordt uitgevoerd. Zypper stopt met een geheugentoewijzingsfout. Het onderstaande voorbeeld is illustratief en geen verslag van een echt incident of test; gebruik de commando's om bewijsmateriaal op je eigen host te verzamelen voordat je een oplossing kiest.

1. Controleer of de server nog steeds wordt geüpgraded.

Start de computer niet opnieuw op, beëindig geen pakketprocessen en voer geen tweede upgradeopdracht uit alleen omdat de SSH-sessie een foutmelding gaf. Maak opnieuw verbinding in een tweede sessie en controleer of er actieve Zypper- of RPM-processen zijn.

pgrep -a 'zypper|rpm'

Als er nog een pakketverwerkingsproces actief is, geef het dan even de tijd en controleer de uitvoer of logbestanden. Verwijder geen Zypper-vergrendelingsbestanden terwijl er mogelijk een pakketverwerkingsproces gaande is. Als er geen proces actief is, bewaar dan de exacte foutmelding en noteer wanneer deze is opgetreden; die tijdstempel helpt bij het correleren van de kernel- en pakketlogbestanden.

2. Bevestig of sluit geheugendruk uit.

Maak een momentopname van het huidige RAM-geheugen en swapgeheugen:

free -h
swapon --show
vmstat 1 5

free -hControleer in de availablekolom, niet alleen het aangegeven bedrag free; Linux gebruikt ook RAM voor de cache. swapon --showgeeft aan of er swap bestaat en hoeveel ervan wordt gebruikt. In vmstatgeven herhaalde niet- sinulwaarden soin de recente rijen aan dat er actief geswapt wordt; de eerste rij is een gemiddelde sinds het opstarten, dus concentreer je op de latere rijen.

Zoek vervolgens naar een kernel out-of-memory (OOM) kill rondom de fout en lees het Zypper-logboek:

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

Een OOM-kill-melding met de naam RPM, Zypper of een ander proces ondersteunt een echte diagnose van geheugenproblemen. Een laag "vrij" RAM-geheugen alleen is geen indicatie: de cache kan worden vrijgemaakt en de melding kan ook het gevolg zijn van een geheugenlimiet van een proces of service. Als er geen kernel-OOM-melding verschijnt, controleer dan de limieten van de mislukte opdracht en eventuele geheugenlimieten van systemd of de container voordat u hostgeheugen toevoegt. De exacte oorzaak kan niet worden vastgesteld aan de hand van de melding "Kan geen geheugen toewijzen" alleen.

3. Verminder de druk voordat u het opnieuw probeert.

Ga terug naar de hypothetische VM. Als de batchtaak veel geheugen verbruikt en het systeem aanhoudende swap-activiteit of een kernel OOM-kill vertoont, gebruik dan de ondersteunde pauze- of stopprocedure van de applicatie. Beëindig geen database, SAP-workload of andere stateful service zonder de afsluitstappen van de operator. Controleer het RAM-geheugen en de swap opnieuw nadat de workload is gepauzeerd.

Als het gastbesturingssysteem tijdens normaal onderhoud geheugen tekortkomt, vergroot dan het toegewezen RAM-geheugen via de ondersteunde hypervisor of het cloud-controlplane en controleer of het besturingssysteem de nieuwe hoeveelheid herkent. Het toevoegen van swapgeheugen kan tijdelijk extra geheugenruimte bieden, maar is trager dan RAM en lost de aanhoudende geheugenbehoefte niet op. De opslagindeling van SLES is van belang: SUSE documenteert bijvoorbeeld specifieke beperkingen voor swapbestanden op Btrfs. Vermijd het aanmaken of wijzigen van swapgeheugen tijdens een upgrade, tenzij u de vereisten voor het bestandssysteem, de snapshots en het platform hebt gecontroleerd.

Als er geen OOM-records (Out of Memory) aanwezig zijn, onderzoek dan de limiet die van toepassing is op het proces dat de fout veroorzaakt. Controleer in SLES 15 de geconfigureerde geheugenlimiet van een door systemd beheerde workload. Vervang de voorbeeldnaam van de unit door de betreffende service:

sudo systemctl show example-batch.service -p MemoryMax

Vergelijk die waarde met het beschikbare geheugen. Een cgroup-limiet wordt niet verholpen door het RAM-geheugen van de VM te vergroten, tenzij de limiet zelf ook dienovereenkomstig wordt verhoogd. Controleer bij oudere servicepacks de naam van de eigenschap aan de hand van de systemd-documentatie van die release.

4. Hervat dezelfde ondersteunde upgrade en controleer of deze is voltooid.

Nadat het pakketverwerkingsproces is voltooid, controleert u /var/log/zypper.logde laatst uitgevoerde actie en eventuele mislukte pakketten. Als RPM of Zypper een onvolledige transactie meldt, volgt u de herstelinstructies van SUSE voor die specifieke fout voordat u het opnieuw probeert. Verwijder geen pakketdatabasebestanden of vergrendelingen handmatig.

Gebruik hetzelfde upgradepad waarmee u oorspronkelijk bent begonnen. Routinematig pakketonderhoud en een servicepackmigratie zijn verschillende bewerkingen: SUSE documenteert zypper patchde installatie van de betreffende patches, terwijl servicepack- en major-release-upgrades hun eigen ondersteunde paden en voorbereidingen hebben. Schakel niet zypper dupzomaar over naar deze methode als tijdelijke oplossing uit geheugen. Controleer voor een routinematige patch-uitvoering eerst de transactie:

sudo zypper patch --dry-run

Als de testrun een redelijk plan laat zien en het geheugen stabiel is, plan dan een onderhoudsvenster in en voer de juiste opdracht uit voor uw oorspronkelijke taak. Houd de SSH-sessie beschikbaar, volg het proces en controleer het resultaat achteraf.

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

Een succesvol herstel betekent dat de beoogde pakketten of migratie zijn voltooid, Zypper correct is afgesloten en er tijdens de uitvoering geen nieuwe OOM-gebeurtenis is opgetreden. Als het systeem opstartbaar is, maar een SLES-servicepackmigratie zelf moet worden teruggedraaid, is de door SUSE gedocumenteerde Snapper-rollback alleen van toepassing als aan de vereisten is voldaan, waaronder een ondersteunde Btrfs-root en geconfigureerde snapshots. Beschouw rollback niet als een algemene reactie op een mislukte pakketpatch.

Wanneer moet je stoppen en wanneer moet je de situatie escaleren?

Als de fout zich herhaalt nadat de geheugendruk is verlicht, pakketprocessen nog steeds vastlopen of de RPM-database corruptie meldt, stop dan met opnieuw proberen. Bewaar het Zypper-logboek, het kernel-logboek, het product- en servicepackniveau en de exacte gebruikte opdracht. SUSE supportconfigkan diagnostische gegevens verzamelen voor een supportaanvraag. De hier beschreven stappen helpen om geheugendruk te onderscheiden van andere toewijzingsfouten; ze kunnen een productspecifiek defect niet vaststellen zonder de volledige logboeken en systeemconfiguratie.

Raadpleeg voor actuele informatie over SLES 15 SP7 de systeemmonitoringtools van SUSE , de referentie voor logbestanden , de beheerhandleiding voor Zypper , de vereisten voor swap en Btrfs , en de online instructies voor upgrades en terugdraaien . Opdrachten en herstelprocedures kunnen variëren afhankelijk van het SLES-servicepack, de architectuur, het bestandssysteem en of het gaat om het toepassen van patches of het migreren naar een nieuwe release.