Urmăriți erorile de memorie la actualizarea SLES înainte de a reîncerca

Dacă SLES raportează mesajul „Nu se poate aloca memorie” în timpul unei actualizări, verificați mai întâi dacă kernelul a înregistrat un eveniment de memorie insuficientă și dacă memoria RAM sau memoria swap a fost epuizată. Întrerupeți o sarcină de lucru neesențială cunoscută sau măriți memoria atribuită mașinii virtuale numai după confirmarea presiunii, apoi verificați dacă Zypper și RPM nu mai sunt active înainte de a relua procedura inițială de actualizare.

Exemplu ipotetic: imaginați-vă o mașină virtuală SLES 15 în care un administrator pornește o actualizare programată a pachetului în timp ce rulează o lucrare batch mare. Zypper se oprește cu o eroare de alocare a memoriei. Exemplul de mai jos este ilustrativ, nu este un raport al unui incident sau test real; utilizați comenzile pentru a colecta dovezi pe propria gazdă înainte de a alege o soluție.

1. Verificați dacă serverul este încă în curs de actualizare

Nu reporniți, nu închideți procesele pachetului și nu lansați o a doua comandă de actualizare doar pentru că sesiunea SSH a afișat o eroare. Reconectați-vă într-o a doua sesiune și verificați dacă există procese Zypper sau RPM active:

pgrep -a 'zypper|rpm'

Dacă un proces al pachetului rulează încă, acordați-i timp și inspectați rezultatul sau jurnalele sale. Nu ștergeți fișierele de blocare Zypper în timp ce o operațiune a pachetului este activă. Dacă niciun proces nu rulează, păstrați textul exact al erorii și notați când a apărut; această marcaj temporal ajută la corelarea jurnalelor kernelului și ale pachetului.

2. Confirmați sau excludeți presiunea memoriei

Colectați o memorie RAM curentă și schimbați instantaneul:

free -h
swapon --show
vmstat 1 5

În free -h, verificați availablecoloana, nu doar cantitatea marcată free; Linux folosește și RAM pentru cache. swapon --showraportează dacă există swap și cât este utilizat. În vmstat, valorile repetate diferite de zero siși sodin rândurile recente indică swapping activ; primul rând este o medie de la pornire, deci concentrați-vă pe rândurile ulterioare.

Apoi, căutați o eroare de tip „kernel out-of-memory” (OOM) în jurul erorii și citiți jurnalul 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

O înregistrare OOM-kill care denumește RPM, Zypper sau un alt proces susține un diagnostic real de presiune a memoriei. Memoria RAM „liberă” redusă nu este suficientă: memoria cache poate fi recuperată, iar mesajul poate rezulta și dintr-o limită de memorie a unui proces sau a unui serviciu. Dacă nu apare nicio intrare OOM în kernel, verificați limitele comenzii eșuate și orice limită de memorie systemd sau container înainte de a adăuga memorie gazdă. Cauza exactă nu poate fi identificată doar din sintagma „Nu se poate aloca memoria”.

3. Reduceți presiunea înainte de a reîncerca

Reveniți la mașina virtuală ipotetică. Dacă jobul batch consumă memorie și sistemul prezintă o activitate swap susținută sau o întrerupere OOM a kernelului, utilizați procedura de pauză sau oprire acceptată de aplicație. Nu terminați o bază de date, o sarcină de lucru SAP sau un alt serviciu cu stare fără pașii de oprire ai operatorului. Verificați memoria RAM și swap-ul din nou după ce sarcina de lucru este întreruptă.

Dacă memoria guestului rămâne insuficientă în timpul întreținerii normale, măriți memoria RAM alocată prin intermediul hypervisorului sau planului de control în cloud acceptat, apoi confirmați că sistemul de operare vede noua cantitate. Adăugarea de fișiere swap poate oferi spațiu temporar, dar este mai lentă decât memoria RAM și nu remediază cererea susținută de memorie. Aspectul stocării SLES este important: de exemplu, SUSE documentează constrângeri specifice pentru fișierele swap pe Btrfs. Evitați crearea sau redimensionarea fișierelor swap în timpul unei actualizări, cu excepția cazului în care ați verificat cerințele sistemului de fișiere, instantaneului și platformei.

Când înregistrările OOM lipsesc, investigați limita care se aplică procesului care eșuează. Pe SLES 15, inspectați limita de memorie configurată a unei sarcini de lucru gestionate de systemd, înlocuind numele unității eșantion cu serviciul afectat:

sudo systemctl show example-batch.service -p MemoryMax

Comparați acea valoare cu memoria disponibilă. O limită a grupului de procesare nu va fi remediată prin creșterea memoriei RAM a mașinii virtuale, cu excepția cazului în care limita este, de asemenea, crescută în mod corespunzător. Pe pachetele service pack mai vechi, confirmați numele proprietății cu documentația systemd a versiunii respective.

4. Reluați aceeași actualizare acceptată și verificați-o

După ce procesul de creare a pachetului s-a încheiat, verificați /var/log/zypper.logultima acțiune finalizată și orice pachet eșuat. Dacă RPM sau Zypper raportează o tranzacție incompletă, urmați instrucțiunile de recuperare SUSE pentru eroarea respectivă înainte de a încerca din nou. Nu eliminați manual fișierele bazei de date a pachetului sau blocările.

Folosiți aceeași cale de actualizare pe care ați început-o inițial. Întreținerea de rutină a pachetelor și migrarea unui service pack sunt operațiuni diferite: documentele SUSE zypper patchsunt folosite pentru instalarea patch-urilor lansate aplicabile, în timp ce upgrade-urile service pack și major-layout au propriile căi acceptate și pregătiri. Nu treceți la zypper dupdoar ca o soluție temporară pentru memorie. Pentru o rulare de rutină a unui patch, examinați mai întâi tranzacția:

sudo zypper patch --dry-run

Dacă simularea prezintă un plan rezonabil și memoria este stabilă, programați o fereastră de mentenanță și executați comanda corespunzătoare pentru sarcina inițială. Mențineți sesiunea SSH disponibilă, monitorizați procesul și verificați rezultatul ulterior:

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

O recuperare reușită înseamnă că pachetele sau migrarea dorite s-au finalizat, Zypper s-a închis fără probleme și nu a apărut niciun eveniment OOM nou în timpul rulării. Dacă sistemul este bootabil, dar o migrare a pachetului service pack SLES trebuie inversată, revenirea documentată a Snapper de la SUSE se aplică numai atunci când cerințele sale sunt îndeplinite, inclusiv o rădăcină Btrfs acceptată și snapshot-uri configurate. Nu tratați revenirea ca un răspuns generic la un patch de pachet eșuat.

Când să te oprești și să escaladezi

Dacă eroarea se repetă după ce presiunea asupra memoriei este eliberată, procesele pachetului sunt încă blocate sau baza de date RPM raportează coruperea, opriți reîncercarea. Păstrați jurnalul Zypper, jurnalul kernelului, nivelul produsului și al pachetului de service și comanda exactă utilizată. SUSE supportconfigpot colecta date de diagnosticare pentru un caz de asistență. Pașii de aici ajută la distingerea presiunii asupra memoriei de alte erori de alocare; nu pot determina un defect specific produsului fără jurnalele complete și configurația sistemului.

Pentru detalii actuale despre SLES 15 SP7, consultați utilitarele de monitorizare a sistemului SUSE , referința fișierelor jurnal , îndrumările de administrare Zypper , cerințele swap și Btrfs și instrucțiunile online de actualizare și revenire la versiunea inițială . Comenzile și căile de recuperare pot varia în funcție de pachetul de service SLES, arhitectură, sistem de fișiere și dacă sarcina este de aplicare a patch-urilor sau de migrare a versiunii.