Remedierea erorii „Nu se poate aloca memorie” în timpul unei actualizări a sistemului SLES

Actualizarea SLES pare să fie în progres, apoi un terminal, un program de instalare sau un jurnal de migrare raportează „Nu se poate aloca memorie”. Mesajul în sine nu dovedește că serverul are nevoie de mai multă memorie RAM fizică. Eroarea ar putea proveni din cauza presiunii memoriei, a unei limite de mașină virtuală sau de serviciu, a unui swap lipsă sau inutilizabil sau a mediului de actualizare în sine. Mai întâi, identificați ce proces și fază de actualizare au produs mesajul; remedierea sigură depinde de acest detaliu.

Versiunea contează. Începând cu octombrie 2026, ghidul de actualizare a versiunii majore SLES 16.0 de la SUSE descrie un sistem de migrare a distribuției care pornește o imagine dedicată de actualizare live, în timp ce migrările pachetelor service pack SLES 15 utilizează fluxul de lucru de migrare YaST sau Zypper stabilit. Nu aplicați o corecție destinată unei migrări online a pachetelor service pack la o actualizare a versiunii majore fără a verifica procedura versiunii dvs. SUSE documentează calea actuală SLES 16 în ghidul său de actualizare SLES 16 .

1. Identificați faza deficitară înainte de a schimba ceva

Înregistrați eroarea completă, marcajul temporal, comanda sau ecranul în care a apărut și dacă sistemul a repornit într-o imagine de instalare sau de migrare. „Nu se poate aloca memoria” este o eroare generală a sistemului de operare, așa că liniile din jur sunt adesea mai utile decât mesajul în sine.

• Înainte de începerea tranzacției pachetului: este posibil ca un proces de înregistrare, depozit, pregătire pentru migrare sau instalare să eșueze. Verificați memoria sistemului și a procesului, apoi examinați jurnalul de servicii sau de migrare relevant.
• În timp ce pachetele sunt instalate sau eliminate: Zypper și RPM ar fi putut deja modifica sistemul. Nu închideți procesul, nu reporniți sistemul și nu porniți un al doilea manager de pachete doar pentru că progresul pare lent. Verificați consola și jurnalele și permiteți procesului de migrare suportat să se finalizeze sau să ajungă într-o stare clară de eroare.
• După o repornire într-o imagine de actualizare: procesul poate rula cu un mediu de resurse diferit de sistemul de operare original. O zonă de swap vizibilă înainte de repornire nu dovedește că imaginea de actualizare o poate utiliza.

Secvența de migrare SLES 16 a SUSE pregătește mediul de migrare, montează sistemele de fișiere, configurează rețeaua, pregătește Zypper, actualizează pachetele, actualizează încărcătorul de boot și repornește sistemul. Ghidul precizează că o eroare înainte de începerea actualizării readuce sistemul la starea inițială; aceasta nu înseamnă că fiecare eroare din timpul înlocuirii pachetelor este inofensivă. Păstrați jurnalele și evitați pașii manuali de recuperare până când știți care etapă a eșuat.

2. Verificați memoria RAM, swap-ul și mesajele recente ale kernelului

Dacă sistemul SLES original încă rulează sau ați ajuns la o shell de recuperare, începeți cu verificări doar pentru citire:

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

free -hrezumă memoria și swap-urile. Concentrați-vă pe memoria disponibilă și swap-urile utilizate, nu doar pe coloana „liberă”: Linux folosește RAM altfel inactivă pentru cache-uri. vmstatajută la afișarea dacă mașina paginază continuu. Lista de procese poate dezvălui o bază de date, un serviciu Java, o copie de rezervă sau altă sarcină de lucru care consumă memorie în timpul actualizării.

Căutați înregistrări OOM ale kernelului în jurul momentului erorii:

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

Dacă eroarea s-a produs mai devreme, modificați fereastra de timp. Un mesaj de kernel care denumește un proces închis este o dovadă a unui eveniment de memorie insuficientă; lipsa unei linii potrivite nu exclude toate erorile de alocare. Dacă actualizarea are loc într-un mediu live separat, inspectați jurnalele acelui mediu atunci când sunt disponibile, în loc să vă bazați doar pe jurnalul vechiului sistem.

Verificați și dacă o mașină virtuală, un container sau o unitate systemd are o limită de memorie. Un guest poate avea memorie disponibilă pe gazdă, dar totuși să atingă propria limită configurată. Pe SLES 16, SUSE documentează cgroups v2 ca ierarhie implicită de control al resurselor și explică faptul că systemd poate aplica limite de resurse. Examinați configurația relevantă a mașinii virtuale sau MemoryMaxsetările serviciului în loc să creșteți limitele globale ale kernelului în mod aleatoriu. Consultați ghidul SUSE SLES 16 kernel control groups .

3. Reduceți utilizarea memoriei concurente și reîncercați doar într-un punct sigur

Dacă măsurătorile arată că o sarcină de lucru utilizează cea mai mare parte a memoriei disponibile, programați o fereastră de întreținere și opriți complet serviciile neesențiale înainte de a reîncerca. Exemplele includ lucrătorii de aplicații care utilizează multă memorie, joburile de analiză, bazele de date de testare și procesele de backup. Nu opriți orbește serviciile de stocare, cluster sau aplicații pe o gazdă de producție; utilizați procedura de oprire documentată a aplicației și confirmați că oprirea acesteia nu va întrerupe utilizatorii sau o sarcină de recuperare.

Pentru o mașină virtuală, comparați memoria RAM configurată a invitatului cu capacitatea gazdei și cererea actuală a altor invitați. Dacă invitatul este subdimensionat, măriți memoria atribuită utilizând metoda acceptată de hipervizor. Adăugarea la cald a memoriei depinde de hipervizor, configurația invitatului și volumul de lucru; planificați o repornire dacă este necesar. În cloud-ul public, verificați dimensiunea instanței și orice limite de memorie specifice furnizorului.

Dacă mesajul persistă în timp ce mașina are suficientă memorie RAM disponibilă și nicio înregistrare OOM, investigați limitele procesului. Pentru un proces care încă rulează, inspectați-l /proc/PID/limitsfolosind ID-ul său real de proces. Pentru un ajutor de actualizare gestionat de systemd, inspectați setările de resurse ale unității. O limită poate constrânge un proces chiar și atunci când gazda are memorie liberă. Modificați o limită numai dacă puteți identifica setarea aplicabilă și înțelege impactul acesteia.

După ce ați abordat constrângerea identificată, reluați sau reîncercați numai prin metoda de actualizare acceptată pentru versiunea SLES și calea de actualizare exactă. Pentru migrarea pachetului service pack SLES 15, utilizați fluxul de lucru documentat pentru migrarea YaST sau Zypper. Pentru migrarea versiunii majore SLES 16, urmați procedura de migrare a distribuției SLES 16. Ghidul SLES 15 SP7 de la SUSE explică fluxul de lucru pentru pachetul service pack și cerințele preliminare de revenire acceptate în documentația online de actualizare .

4. Luați în considerare schimbarea cu atenție; nu o folosiți ca o soluție orbească

Un swap suplimentar poate oferi unui sistem mai mult spațiu de memorie virtuală atunci când sarcina de lucru poate pagina memoria, dar este mult mai lent decât memoria RAM. Dacă mașina efectuează deja swaps intens, adăugarea unui swap suplimentar poate face ca actualizarea să fie extrem de lentă, fără a rezolva o mașină virtuală subdimensionată sau o limită de proces izolată. Mai întâi confirmați dacă swap există și dacă este utilizat cu swapon --showși free -h.

Folosește procedura SUSE pentru versiunea și sistemul de fișiere SLES dacă trebuie să adaugi fișiere swap. Fii deosebit de atent cu Btrfs: SUSE documentează restricțiile pentru fișierele swap pe Btrfs și precizează că nu se poate crea un snapshot în timp ce un fișier swap din subvolumul sursă este activ. Deoarece SLES se bazează în mod obișnuit pe snapshot-uri Snapper pentru recuperarea sistemului, nu crea și nu activa un fișier swap generic pe subvolumul rădăcină snapshot-uit în timpul unei ferestre de actualizare. Preferă să adaugi RAM sau să utilizezi o partiție swap configurată corect sau o locație acceptată după verificarea aspectului de stocare și a planului de recuperare. Detaliile specifice sistemului de fișiere se găsesc în ghidul de stocare SLES 15 SP7 de la SUSE .

Nu modificați vm.overcommit_memory, nu dezactivați killer-ul OOM și nu rulați o comandă de curățare arbitrară ca prim răspuns. Aceste modificări pot ascunde simptomul, pot destabiliza sarcinile de lucru sau pot îngreuna recuperarea. Adunați mai întâi dovezi și utilizați îndrumările specifice setării de la SUSE sau de la furnizorul aplicației dacă jurnalele indică o configurație specializată a memoriei.

5. Recuperare dacă actualizarea s-a oprit după începerea modificărilor pachetului

Înainte de a decide să rulați din nou o actualizare, verificați dacă managerul de pachete este încă activ și dacă instrumentul de migrare a raportat o eroare finală. Dacă actualizarea s-a oprit după începerea modificărilor pachetului, salvați jurnalul complet și verificați documentația de recuperare specifică versiunii. Nu rulați comenzile zypper dup, zypper migration, migrare YaST și RPM simultan.

Pe SLES 15 SP7, SUSE documentează revenirea la service pack atunci când sistemul de fișiere rădăcină este Btrfs și instantaneele Snapper sunt activate. Procedura de revenire necesită identificarea și testarea instantaneului de dinainte de migrare, apoi permanentizarea revenirii; nu este o soluție universală pentru fiecare eroare de actualizare. Migrarea versiunii majore în SLES 16 urmează un flux de lucru diferit, așadar utilizați instrucțiunile actuale de actualizare și recuperare, în loc să presupuneți că se aplică procedura SLES 15. Dacă sistemul este critic pentru afacere, nu are o copie de rezervă testată sau migrarea eșuează în timpul înlocuirii pachetului, deschideți un caz de asistență SUSE înainte de a încerca reparații manuale ale pachetului.

6. Verificați sistemul înainte de a relua funcționarea normală

După ce actualizarea raportează finalizarea și serverul pornește normal, verificați versiunea sistemului de operare și înregistrarea, apoi verificați consistența pachetului și sarcina de lucru care a expus inițial problema:

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

Folosiți comanda package-verification acceptată de versiunea dvs. de SLES; dacă zypper verifynu este disponibilă sau se comportă diferit în versiunea dvs., consultați zypper helpghidul de administrare al versiunii. Verificați jurnalele aplicației și ale kernelului pentru erori noi, confirmați că serviciile dorite sunt sănătoase și monitorizați memoria și swap-ul în timp ce încărcarea revine. Verificați dacă ținta de actualizare acceptată a fost instalată și dacă înregistrarea și depozitele serverului sunt în starea așteptată înainte de a închide fereastra de întreținere.

O remediere reușită înseamnă mai mult decât o dispariție a mesajului de eroare: migrarea SLES se finalizează utilizând o cale acceptată, mașina pornește în versiunea așteptată, pachetele și înregistrarea se verifică, iar sarcinile de lucru normale rulează fără evenimente OOM repetate. Dacă se returnează eroarea „Nu se poate aloca memorie” în ciuda presiunii reduse a memoriei, a swap-ului adecvat și a lipsei unei limite de resurse, păstrați detaliile precise ale jurnalului și procesului - aceste indicii disting un defect de actualizare de o problemă de capacitate.