Lee las advertencias de memoria y disco antes de actualizar.

Cattura una piccola linea di base con contesto

Usa un account Linux autorizzato a ispezionare l'applicazione che gestisci. I comandi qui ispezionano lo stato; non rimuovono file né ridimensionano lo storage. Alcune directory e journal richiedono accesso elevato. Sostituisci /var/lib/field-api, /opt/field-api y /opt/first-api con percorsi reali dell'applicazione e conferma che tali percorsi esistano prima di interpretare i risultati.

Registra l'ora, la versione corrente e l'attività: traffico ordinario, un upload, un lavoro di report o una build di deployment. Prendi un'altra lettura durante un'attività comparabile. Due screenshot non correlati possono far sembrare incoerente una macchina sana. Se gli utenti sono già interessati, cattura il primo indizio utile dalla guida agli errori dell'applicazione prima di apportare più modifiche contemporaneamente.

Leggi la memoria disponibile, poi ispeziona il carico di lavoro

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

In free, la memoria disponibile stima ciò che potrebbe essere utilizzato per nuove applicazioni senza swapping. Tiene conto della cache recuperabile, quindi risponde a una domanda diversa dalla memoria "libera" completamente inutilizzata. Vedi il manuale upstream di free. Linux usa la memoria per la cache dei file; una cache grande da sola non è prova di una perdita. La panoramica sulla memoria del kernel spiega perché cache e memoria dell'applicazione coesistono.

Lettura illustrativa, non una misurazione del server: un piccolo host ha circa 1.9 GiB di memoria utilizzabile, 80 MiB liberi e 850 MiB disponibili. Il valore basso di memoria libera da solo non giustifica un upgrade. Se la memoria disponibile scende ripetutamente vicino a zero durante un report, le richieste rallentano e compaiono messaggi rilevanti di allocazione o out-of-memory, quella prova combinata merita un'indagine.

El ps il comando elenca l'RSS dei processi in KiB, dal più grande. L'RSS descrive la memoria residente, non una contabilità completa della proprietà esclusiva; le pagine condivise possono comparire in più processi. Non sommare ogni valore RSS e trattare il risultato come l'utilizzo esatto dell'host. Il riferimento upstream di ps definisce RSS e ordinamento. Registra il nome del processo e se il suo footprint ritorna verso il livello precedente dopo la fine del carico di lavoro.

Lo swap in uso può riflettere attività precedenti; da solo non prova una pressione attuale. Distingui anche la capacità dell'host dai limiti del servizio o del container. Un processo limitato può fallire mentre l'host ha ancora memoria disponibile. Ispeziona il limite configurato e il momento del guasto prima di aumentare la dimensione del VPS. Il riferimento del kernel al filesystem proc documenta i campi di memoria dietro queste osservazioni.

Trova il filesystem che si sta effettivamente riempiendo

df -h / /opt/first-api
df -i / /opt/first-api

Il primo comando riporta lo spazio sui filesystem che contengono quei percorsi. Il secondo riporta gli inode, che sono record del filesystem necessari per file e directory. Un carico di lavoro con molti file minuscoli può esaurire gli inode mentre la capacità in byte rimane. Controlla il mount e entrambi i tipi di capacità invece di usare la dimensione dell'intero VPS come unico numero. Vedi il manuale GNU di df.

Un percorso su un volume montato separatamente può riempirsi indipendentemente dal filesystem root. Al contrario, due percorsi elencati possono appartenere allo stesso filesystem, quindi il loro spazio disponibile non è additivo. Anche le riserve del filesystem, le quote e gli strati di storage possono influire su ciò che l'app può scrivere. Una singola percentuale visualizzata non identifica il proprietario della crescita.

Attribuisci la crescita a log, upload o artefatti

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du stima lo spazio allocato sotto ogni directory. Qui -x evita di attraversare un altro filesystem, -h usa unità leggibili e -d1 limita la profondità visualizzata. Gli alberi grandi possono comunque richiedere tempo e attività del disco per essere scansionati. Gli errori di autorizzazione significano che la vista è incompleta. Vedi il manuale GNU di du. Il comando journal riporta lo storage del journal, inclusi file attivi e archiviati, come documentato da journalctl.

Confronta le directory più grandi con il loro scopo:

• Log: un errore ripetuto ha aumentato il volume, e la rotazione è configurata?
• Upload: i file utente conservati crescono come previsto, e gli upload parziali abbandonati sono contabilizzati?
• Artefatti di rilascio: le vecchie build si accumulano oltre la politica di rollback?
• File del database: gli strumenti propri del database spiegano la crescita e le esigenze di manutenzione?

Non eliminare una directory di database sconosciuta né usare una pulizia ampia dei volumi dei container come passo di indagine. Identifica prima la proprietà, i requisiti di conservazione e una copia recuperabile. Se df e i totali delle directory discordano sostanzialmente, ispeziona i confini dei mount, gli errori di accesso e i file ancora tenuti aperti dopo l'eliminazione con un operatore esperto; eliminare ripetutamente i file visibili può non liberare lo spazio occupato.

Trasforma le letture in un'azione successiva specifica

Caso illustrativo: la memoria disponibile rimane confortevole, ma una directory di upload cresce di circa 400 MiB in ciascuno di due giorni osservati. Il filesystem ha circa 2 GiB disponibili. Dividendo lo spazio rimanente per quella crescita a breve termine si suggeriscono solo circa cinque giorni allo stesso ritmo, prima di lasciare margine operativo. Questa è una stima di pianificazione, non una previsione né una scadenza sicura fino alla quale attendere; gli upload e il lavoro temporaneo possono arrivare in modo irregolare.

L'azione successiva è controllare la conservazione degli upload e la domanda prevista, pianificare storage aggiuntivo se giustificato e impostare un avviso abbastanza presto da agire. Più RAM non risolverebbe questa scoperta. In un caso diverso, una build di deployment potrebbe creare un breve picco di memoria mentre il servizio resta piccolo; spostare la build fuori dal VPS potrebbe essere più utile che ingrandire permanentemente il runtime.

Dopo una modifica giustificata, ripeti le stesse letture e un'azione dell'applicazione. Conferma che lo spazio sia effettivamente disponibile e che i dati previsti funzionino ancora. Mantieni eliminazione e ridimensionamento come operazioni pianificate con passaggi di recupero, non come risposte automatiche a un numero rosso. Usa la guida al budget delle risorse per trasformare un'esigenza dimostrata in scelte di configurazione, e fai pratica con il ripristino prima di dipendere da una pulizia o una migrazione.