Risolvere il problema "Impossibile allocare memoria" durante un aggiornamento del sistema SLES

L'aggiornamento di SLES sembra procedere, ma poi un terminale, il programma di installazione o il log di migrazione segnalano il messaggio "Impossibile allocare memoria". Questo messaggio di per sé non dimostra che il server necessiti di più RAM fisica. L'errore potrebbe derivare da problemi di memoria, da un limite di macchine virtuali o servizi, da una partizione di swap mancante o inutilizzabile, oppure dall'ambiente di aggiornamento stesso. Innanzitutto, è necessario identificare il processo e la fase di aggiornamento che hanno generato il messaggio; la soluzione sicura dipende da questo dettaglio.

La versione è importante. A partire da ottobre 2026, la guida di SUSE per l'aggiornamento alla versione principale SLES 16.0 descrive un sistema di migrazione della distribuzione che avvia un'immagine di aggiornamento live dedicata, mentre le migrazioni dei service pack di SLES 15 utilizzano il flusso di lavoro di migrazione consolidato YaST o Zypper. Non applicare una correzione destinata a una migrazione online di un service pack a un aggiornamento di versione principale senza aver prima verificato la procedura specifica per la propria release. SUSE documenta il percorso attuale per SLES 16 nella sua guida di aggiornamento a SLES 16 .

1. Individua la fase critica prima di apportare qualsiasi modifica.

Registra l'errore completo, la data e l'ora, il comando o la schermata in cui è apparso e se il sistema è stato riavviato con un'immagine di installazione o di migrazione. "Impossibile allocare memoria" è un errore generico del sistema operativo, quindi le righe circostanti sono spesso più utili del solo messaggio.

• Prima dell'avvio della transazione del pacchetto: un processo di registrazione, repository, preparazione alla migrazione o installazione potrebbe non riuscire. Verificare la memoria di sistema e di processo, quindi esaminare il registro del servizio o della migrazione pertinente.
• Durante l'installazione o la rimozione dei pacchetti: Zypper e RPM potrebbero aver già modificato il sistema. Non interrompere il processo, non riavviare il computer e non avviare un secondo gestore di pacchetti solo perché l'avanzamento sembra lento. Controlla la console e i log e attendi che il processo di migrazione supportato termini o raggiunga un chiaro stato di errore.
• Dopo un riavvio con un'immagine di aggiornamento: il processo potrebbe essere in esecuzione con un ambiente di risorse diverso da quello del sistema operativo originale. La presenza di un'area di swap visibile prima del riavvio non garantisce che l'immagine di aggiornamento possa utilizzarla.

La sequenza di migrazione di SUSE SLES 16 prepara l'ambiente di migrazione, monta i filesystem, configura la rete, prepara Zypper, aggiorna i pacchetti, aggiorna il boot loader e riavvia il sistema. La guida afferma che un errore prima dell'avvio dell'aggiornamento ripristina il sistema allo stato originale; ciò non significa che ogni errore durante la sostituzione dei pacchetti sia innocuo. Conserva i log ed evita di eseguire operazioni di ripristino manuali finché non hai individuato la fase che ha causato l'errore.

2. Controllare la RAM, lo swap e i messaggi recenti del kernel.

Se il sistema SLES originale è ancora in esecuzione o se hai raggiunto una shell di ripristino, inizia con i controlli di sola lettura:

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

free -hRiepiloga la memoria e lo swap. Concentrati sulla memoria disponibile e sullo swap utilizzato, non solo sulla colonna "libera": Linux utilizza la RAM altrimenti inattiva per le cache. vmstatAiuta a mostrare se la macchina sta continuamente eseguendo il paging. L'elenco dei processi può rivelare un database, un servizio Java, un backup o un altro carico di lavoro che consuma memoria durante l'aggiornamento.

Cercare eventuali record di errore di memoria insufficiente (OOM) del kernel intorno al momento dell'errore:

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

Se l'errore si è verificato in precedenza, modificare l'intervallo di tempo. Un messaggio del kernel che indica un processo terminato è indice di un evento di memoria insufficiente; l'assenza di una riga corrispondente non esclude tutti gli errori di allocazione. Se l'aggiornamento viene eseguito in un ambiente di produzione separato, esaminare i log di tale ambiente, se disponibili, anziché affidarsi esclusivamente al journal del vecchio sistema.

Verificate inoltre se una macchina virtuale, un container o un'unità systemd hanno un limite di memoria. Una macchina virtuale guest può avere memoria disponibile sull'host ma raggiungere comunque il proprio limite configurato. Su SLES 16, SUSE documenta cgroups v2 come gerarchia di controllo delle risorse predefinita e spiega che systemd può applicare limiti alle risorse. Esaminate la configurazione della macchina virtuale o l' MemoryMaximpostazione del servizio pertinente anziché aumentare i limiti globali del kernel in modo casuale. Consultate la guida di SUSE sui gruppi di controllo del kernel per SLES 16 .

3. Riduci l'utilizzo della memoria in competizione e riprova solo in un punto sicuro

Se le misurazioni mostrano che un carico di lavoro sta utilizzando la maggior parte della memoria disponibile, pianifica una finestra di manutenzione e arresta correttamente i servizi non essenziali prima di riprovare. Esempi includono i processi applicativi che utilizzano molta memoria, i processi di analisi, i database di test e i processi di backup. Non arrestare indiscriminatamente i servizi di archiviazione, cluster o applicativi su un host di produzione; utilizza la procedura di arresto documentata dell'applicazione e verifica che l'arresto non interrompa gli utenti o un'attività di ripristino.

Per una macchina virtuale, confronta la RAM configurata per la macchina virtuale con la capacità dell'host e con la richiesta attuale delle altre macchine virtuali. Se la memoria assegnata alla macchina virtuale è insufficiente, aumentala utilizzando il metodo supportato dall'hypervisor. La possibilità di aggiungere memoria a caldo dipende dall'hypervisor, dalla configurazione della macchina virtuale e dal carico di lavoro; pianifica un riavvio se necessario. Nel cloud pubblico, verifica le dimensioni dell'istanza e gli eventuali limiti di memoria specifici del provider.

Se il messaggio persiste nonostante la macchina disponga di RAM sufficiente e non vi siano segnalazioni di esaurimento della memoria (OOM), è necessario verificare i limiti di processo. Per un processo ancora in esecuzione, ispezionarlo /proc/PID/limitsutilizzando il suo ID di processo effettivo. Per un'unità di supporto all'aggiornamento gestita da systemd, controllare le impostazioni delle risorse dell'unità. Un limite può limitare un processo anche quando l'host dispone di memoria libera. Modificare un limite solo se si è in grado di identificare l'impostazione applicabile e comprenderne l'impatto.

Dopo aver risolto il problema identificato, riprendere o riprovare solo tramite il metodo di aggiornamento supportato per la versione specifica di SLES e il percorso di aggiornamento in uso. Per la migrazione del service pack di SLES 15, utilizzare il flusso di lavoro di migrazione documentato di YaST o Zypper. Per la migrazione della versione principale di SLES 16, seguire la procedura di migrazione della distribuzione di SLES 16. La guida di SUSE per SLES 15 SP7 illustra il flusso di lavoro del service pack e i prerequisiti di rollback supportati nella documentazione di aggiornamento online .

4. Valutate attentamente lo scambio; non utilizzatelo come soluzione cieca.

L'aggiunta di swap può fornire al sistema un margine di memoria virtuale maggiore quando il carico di lavoro può utilizzare la memoria di paging, ma è molto più lenta della RAM. Se la macchina utilizza già intensamente lo swap, aggiungerne altro può rendere l'aggiornamento estremamente lento senza risolvere un problema di VM sottodimensionata o di limitazione di un singolo processo. Innanzitutto, verificare se lo swap è presente e se viene utilizzato con swapon --showe free -h.

Se devi aggiungere una partizione di swap, segui la procedura SUSE specifica per la tua versione di SLES e il tuo filesystem. Presta particolare attenzione a Btrfs: SUSE documenta le restrizioni relative ai file di swap su Btrfs e specifica che non è possibile creare uno snapshot mentre un file di swap nel sottovolume di origine è attivo. Poiché SLES si basa comunemente sugli snapshot di Snapper per il ripristino del sistema, non creare e attivare un file di swap generico sul sottovolume root dello snapshot durante una finestra di aggiornamento. È preferibile aggiungere RAM o utilizzare una partizione di swap configurata correttamente o una posizione supportata, dopo aver verificato la configurazione dello storage e il piano di ripristino. I dettagli specifici per il filesystem sono disponibili nella guida allo storage di SLES 15 SP7 di SUSE .

Non modificare vm.overcommit_memory, disabilitare l'OOM killer o eseguire comandi di pulizia arbitrari come prima risposta. Queste modifiche possono mascherare il sintomo, destabilizzare i carichi di lavoro o rendere più difficile il ripristino. Raccogli prima le prove e, se i log indicano una configurazione di memoria particolare, segui le indicazioni specifiche fornite da SUSE o dal fornitore dell'applicazione.

5. Ripristinare l'aggiornamento se si è interrotto dopo l'inizio delle modifiche ai pacchetti.

Prima di decidere di rieseguire un aggiornamento, verificare se il gestore dei pacchetti è ancora attivo e se lo strumento di migrazione ha segnalato un errore finale. Se l'aggiornamento si è interrotto dopo l'inizio delle modifiche ai pacchetti, salvare l'output completo del log e consultare la documentazione di ripristino specifica per la release. Non eseguire contemporaneamente i comandi zypper dup, zypper migration, YaST migration e RPM.

Su SLES 15 SP7, SUSE documenta il rollback del service pack quando il filesystem root è Btrfs e gli snapshot Snapper sono abilitati. La procedura di rollback richiede l'identificazione e il test dello snapshot precedente alla migrazione, quindi la sua modifica diventa permanente; non è una soluzione universale per tutti gli errori di aggiornamento. La migrazione alla versione principale di SLES 16 segue un flusso di lavoro diverso, quindi utilizzare le istruzioni di aggiornamento e ripristino correnti anziché presumere che la procedura di SLES 15 sia applicabile. Se il sistema è critico per l'azienda, non dispone di un backup testato o la migrazione fallisce durante la sostituzione dei pacchetti, aprire un caso di supporto SUSE prima di tentare riparazioni manuali dei pacchetti.

6. Verificare il sistema prima di riprendere il servizio normale

Una volta che l'aggiornamento viene segnalato come completato e il server si avvia normalmente, verificare la versione e la registrazione del sistema operativo, quindi controllare la coerenza dei pacchetti e il carico di lavoro che ha originariamente evidenziato il problema:

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

Utilizzare il comando package-verification supportato dalla versione di SLES in uso; se zypper verifynon è disponibile o si comporta in modo diverso nella propria release, consultare zypper helpla guida di amministrazione della release stessa. Controllare i log delle applicazioni e del kernel per individuare nuovi errori, verificare che i servizi previsti siano integri e monitorare la memoria e lo swap al termine del carico di lavoro. Prima di chiudere la finestra di manutenzione, verificare che l'aggiornamento supportato sia stato installato e che la registrazione del server e i repository siano nello stato previsto.

Una soluzione efficace significa molto più che la semplice scomparsa del messaggio di errore: la migrazione SLES si completa utilizzando un percorso supportato, la macchina si avvia con la versione prevista, i pacchetti e la registrazione vengono verificati correttamente e i carichi di lavoro normali vengono eseguiti senza ripetuti eventi di OOM (Out Of Memory). Se il messaggio "Impossibile allocare memoria" viene visualizzato nonostante una bassa pressione sulla memoria, uno swap adeguato e nessun limite di risorse, è fondamentale conservare i dettagli precisi del log e del processo: questi indizi permettono di distinguere un difetto di aggiornamento da un problema di capacità.