Linux procfs per amministratori: panoramica dei file più importanti

Il sito Linux procfs Mostra lo stato attuale del kernel tramite file virtuali nella directory /proc. Per l’amministrazione sono particolarmente rilevanti il carico di sistema, la memoria, i processi, i descrittori di file e i dispositivi a blocchi. È fondamentale contestualizzare i dati: alcuni valori sono istantanei, altri sono contatori accumulati dall’avvio o medie mobili. Pertanto, non limitarti mai a considerare un singolo valore, ma confrontalo con i segnali appropriati e il contesto dell’host, della macchina virtuale o del container.

Comprendere procfs: una visione virtuale del kernel anziché un’area di memoria

Il sito procfs È un file system virtuale: le voci presenti in /proc rappresentano le strutture dati e gli stati del kernel Linux in esecuzione. Non si tratta di contenuti memorizzati in modo permanente su un supporto dati. Durante la lettura, il kernel genera la rispettiva rappresentazione in base al proprio stato attuale; dopo un riavvio, ad esempio, molti contatori ripartono da zero. Pertanto, /proc è un’interfaccia per il monitoraggio e, in parte, per il controllo, non un luogo in cui memorizzare file propri o configurazioni persistenti.

Per quanto riguarda l'amministrazione, occorre distinguere tre aree. I file di stato globali come /proc/meminfo, /proc/stat o /proc/loadavg forniscono metriche relative all'intero kernel. Le directory con nomi numerici, ad esempio /proc/1234, forniscono dettagli su un singolo processo. In /proc/sys si trovano invece i parametri del kernel, che, a seconda dei permessi e del parametro specifico, possono essere sia leggibili che modificabili. La somiglianza nella struttura dei file non deve trarre in inganno: l’interrogazione dello stato e la modifica della configurazione hanno conseguenze fondamentalmente diverse.

I percorsi e i campi disponibili non sono identici su tutti i sistemi Linux. La versione e la configurazione del kernel, l’architettura, l’hardware rilevato e i moduli caricati influenzano le voci visibili. Anche gli spazi dei nomi modificano le singole visualizzazioni. In particolare, un procfs associato a uno spazio dei nomi PID limita la visualizzazione dei processi e dei PID; ciò non implica tuttavia che i file globali mostrino automaticamente valori specifici del container o del cgroup. Gli script dovrebbero verificare i file e i campi prima di valutarne il contenuto, anziché presupporre una struttura procfs completa e identica ovunque.

Da distinguere da questo è sysfs in /sys: esso rappresenta principalmente dispositivi, driver e oggetti hardware. Per l’allocazione delle risorse e i limiti dei gruppi è rilevante anche cgroup2. procfs rimane tuttavia la fonte diretta per molti stati del kernel e dei processi, necessari per una prima diagnosi.

Interpretare correttamente i dati, le istantanee e la visibilità

Nel caso di procfs, il valore da solo raramente spiega un problema. Innanzitutto occorre chiarirne il riferimento temporale: alcuni dati sono contatori cumulativi dal riavvio del sistema, altri descrivono uno stato attuale, altri ancora rappresentano intervalli di tempo mobili. Un valore elevato del contatore indica inizialmente solo che un evento si è accumulato dal momento dell’avvio. Una frequenza si ottiene solo da due punti di misurazione: la differenza tra i valori divisa per l’intervallo di tempo che li separa. Ciò vale, ad esempio, per molti contatori di CPU, di interrupt e di supporti dati.

Il file /proc/uptime fornisce la durata di funzionamento trascorsa e il tempo di inattività aggregato. Aiuta a contestualizzare temporalmente i contatori dal momento dell’avvio, ma non sostituisce una serie di misurazioni. Una singola interrogazione rappresenta un'istantanea; per ottenere informazioni attendibili su tendenze, picchi o carichi ricorrenti sono necessarie interrogazioni ripetute con timestamp. In questo contesto, i valori possono variare già durante la lettura, poiché il kernel continua a funzionare.

Anche i dati visibili hanno dei limiti. /proc/self rimanda sempre al processo che sta risolvendo il percorso in quel momento. Ciò lo rende pratico per gli script e i controlli interattivi, senza dover specificare un PID. L’accesso alle directory di processi esterni può tuttavia essere limitato dai permessi dei file, dalle capacità di Linux e dall’opzione di mount procfs hidepid essere limitata. In questo caso, la mancanza di informazioni non è dovuta a un malfunzionamento di procfs, ma costituisce una misura di protezione contro la lettura di informazioni sensibili relative ai processi.

È necessario prestare particolare attenzione nei container. Un procfs associato a uno spazio dei nomi PID mostra, nei percorsi relativi ai processi, solo i processi di quella vista dello spazio dei nomi. I file globali del kernel come /proc/meminfo, /proc/stat o /proc/diskstats possono invece continuare a riflettere i valori dell’host e non sono automaticamente limitati ai limiti del container. Prima di qualsiasi diagnosi è quindi necessario chiarire se la questione riguarda i processi, i valori globali del kernel o le risorse effettivamente assegnate; i limiti e l’utilizzo di un container rientrano inoltre nell’analisi cgroup2.

Leggere, configurare e proteggere in /proc/sys

Il settore /proc/sys è la vista del file system dell’interfaccia sysctl. La lettura di un valore serve a fini diagnostici. L'accesso in scrittura, invece, modifica immediatamente il comportamento del kernel in esecuzione e può influire sui servizi, sul consumo di risorse o sulle caratteristiche di sicurezza. Il fatto che una modifica abbia effetto senza il riavvio non la rende priva di rischi né automaticamente permanente: la persistenza dipende dalla configurazione di sistema selezionata.

La struttura delle directory facilita la prima analisi. In /proc/sys/fs si trovano, tra l’altro, i parametri globali relativi al filesystem e agli handle dei file. /proc/sys/vm raggruppa le impostazioni relative alla gestione della memoria, mentre /proc/sys/net contiene i parametri relativi alla rete. La disponibilità delle sottodirectory e delle chiavi dipende, a sua volta, dalla configurazione del kernel e dalle funzionalità del sistema. Un parametro presente non costituisce quindi una ricetta universale per l’ottimizzazione; sono determinanti la sua documentazione e il carico di lavoro specifico.

Un controesempio di apparente ottimizzazione è drop_caches in /proc/sys/vm. La documentazione del kernel attribuisce a questa funzione lo scopo di debug e test e sconsiglia di utilizzarla per scopi diversi da questi, poiché lo svuotamento delle cache riutilizzabili può comportare una perdita di prestazioni. La scarsa disponibilità di memoria libera non è di per sé un motivo per svuotare le cache: il kernel utilizza infatti la RAM anche per la cache dei file.

Prima di ogni modifica dovrebbe esserci una causa ben definita. Assicurati innanzitutto il valore iniziale, documenta lo scopo e gli effetti collaterali previsti, apporta la modifica in modo controllato e osserva successivamente i valori di misurazione e il comportamento del servizio. Pianifica in anticipo il percorso di ritorno e inserisci un valore in una configurazione permanente solo dopo averlo verificato da un punto di vista tecnico. Ulteriori nozioni di base sui parametri e sulla loro gestione controllata sono trattate nell’articolo Messa a punto del kernel nell'hosting Linux: i parametri Sysctl in sintesi.

I file procfs più importanti in base all'attività di amministrazione

La scelta di un file procfs dovrebbe basarsi su esigenze amministrative, non sulla ricerca di un elenco di directory il più completo possibile. I file globali forniscono spesso valori a livello di kernel, i percorsi dei processi descrivono un singolo processo visibile, mentre le voci presenti in /proc/sys/fs forniscono informazioni sulla configurazione e sui limiti a livello di sistema. Alcuni valori rappresentano stati attuali, altri sono contatori cumulativi dal momento dell’avvio o medie mobili. Questa distinzione determina se sia sufficiente una singola lettura o se siano necessari due punti di misurazione.

La tabella è uno strumento di riferimento iniziale, non una sequenza diagnostica. Un valore anomalo richiede sempre una verifica indipendente: il carico con i dati della CPU e dell’I/O, i valori di memoria con le informazioni sullo stall di pressione e le variabili di processo con il comportamento del servizio. In particolare, /proc/diskstats e /proc/stat sono contatori cumulativi; la loro differenza su un intervallo noto è più significativa per i tassi rispetto al valore assoluto. Nei container occorre inoltre verificare se un file fornisce valori globali del kernel o una visione specifica per ciascun cgroup. Le sezioni seguenti classificano quindi i segnali in base al carico, alla memoria, ai processi e all’I/O.

Carico, CPU e memoria: valutazione combinata dei segnali

Se l'applicazione è lenta, /proc/loadavg è un buon punto di partenza, ma non costituisce un giudizio definitivo sulla CPU. I tre valori rappresentano il carico medio degli ultimi 1, 5 e 15 minuti. Nel carico non vengono conteggiate solo le unità pronte all’esecuzione nello stato R, ma anche i task nello stato di attesa non interrompibile D, ad esempio in caso di I/O. Il quarto campo mostra le unità di scheduling attualmente eseguibili rispetto a tutte quelle esistenti. Elevato Media di carico può quindi indicare una situazione di competizione per la CPU, accessi I/O bloccati o entrambi.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

Le righe relative alla CPU in /proc/stat contengono le percentuali di tempo trascorse dall'avvio del sistema in USER_HZ. Per calcolare le percentuali di carico, è necessario confrontare due letture; un singolo valore indica solo il tempo accumulato. Il valore iowait non è una misura diretta della latenza dello storage: il suo calcolo presenta limiti documentati e, in determinate circostanze, può addirittura diminuire. Per individuare una causa legata all’I/O, è quindi utile considerare anche i valori dei dispositivi e l’I/O-PSI.

Anche un valore basso di MemFree non indica necessariamente una carenza di RAM. Linux utilizza in modo mirato la memoria non utilizzata per la cache. MemAvailable stima la quantità di memoria che le nuove applicazioni potrebbero presumibilmente ottenere senza ricorrere allo swapping ed è solitamente più utile per una prima valutazione. Solo quando MemAvailable si riduce e contemporaneamente si verificano dei blocchi di memoria, si rafforza l'indicazione di pressione di accumulo. In un container, tuttavia, questi valori di memoria globali possono provenire dall'host; per le risorse garantite o limitate, è determinante anche la prospettiva cgroup2.

I file presenti in /proc/pressure completano questa visione. Per memory e io, "some" indica che almeno alcuni task non sono riusciti a progredire durante una parte della finestra temporale; "full" indica invece una situazione in cui tutti i task non inattivi erano bloccati contemporaneamente. I valori «avg10», «avg60» e «avg300» si riferiscono rispettivamente a 10, 60 e 300 secondi, mentre «total» è un contatore cumulativo degli stalli. Per la CPU, il valore «full» a livello di sistema non è semanticamente definito e, a partire da Linux 5.13, viene restituito come «null» per motivi di compatibilità; pertanto, non deve essere interpretato come valore diagnostico a livello di sistema. I valori PSI relativi a CPU, memoria e I/O rispondono a domande diverse e non dovrebbero essere utilizzati in modo intercambiabile.

Se un servizio risponde lentamente quando la memoria libera (MemFree) è scarsa, controlla innanzitutto MemAvailable e /proc/pressure/memory. Se entrambi risultano nella norma, ciò esclude una pressione acuta sulla memoria a livello di sistema. Successivamente, /proc//status può indicare se il processo in questione presenta, ad esempio, un valore VmRSS elevato, molti thread o uno stato anomalo. Questa combinazione permette di distinguere un utilizzo della memoria normale, ma con un carico elevato sulla cache, da un problema che richiede un’ulteriore analisi del processo.

Analisi di processi, descrittori di file e I/O su supporto dati

Per eseguire un'operazione in sicurezza con un processo la cui presenza è garantita, $$ indica il PID della shell corrente. Il file "status" è più leggibile rispetto al file "stat", orientato ai campi. Il nome identifica il processo, lo stato ne indica la condizione, PPid il processo padre e Threads il numero di thread. VmRSS è una rapida approssimazione della memoria residente, la cui contabilità RSS è scalabile e asincrona e può quindi risultare imprecisa; VmSize descrive invece lo spazio di indirizzamento virtuale. FDSize descrive la dimensione della tabella dei descrittori, non necessariamente il numero di voci attualmente aperte. I cambi di contesto volontari e involontari possono aiutare a classificare il comportamento di scheduling, ma da soli non costituiscono una prova di errore.

cat /proc/$$/status
ls -l /proc/$$/fd

La directory fd contiene collegamenti simbolici a file aperti, pipe, dispositivi o socket. È utile, ad esempio, per individuare un processo che continua a mantenere aperto un file di log cancellato. Tuttavia, un numero elevato di descrittori di file aperti è del tutto prevedibile in presenza di proxy, database o server orientati agli eventi. Per le viste filtrate e l’assegnazione tra i processi è Utilizzare lsof per l'analisi dei file aperti un'integrazione adeguata. Le righe di comando provenienti da cmdline possono rivelare argomenti riservati; environ è ancora più delicato a causa della presenza di eventuali credenziali di accesso o token e non va interrogato di routine.

maps elenca le aree di memoria virtuali con autorizzazioni, offset, dispositivo, inode e, se del caso, percorso. smaps integra, per ogni mappatura, valori di memoria dettagliati e fornisce un’istantanea più accurata rispetto alle informazioni RSS, ma anche più complessa. Entrambi i file sono destinati ad analisi approfondite della memoria: il loro output può essere voluminoso e l’interpretazione dei singoli mappamenti richiede un contesto. Per una prima analisi, status e i file di memoria e PSI a livello di sistema sono solitamente più efficienti.

In caso di carico elevato e basso utilizzo della CPU, /proc/diskstats amplia la diagnostica a livello di dispositivo. Il file tiene traccia delle statistiche cumulative di I/O per ogni dispositivo a blocchi. Per valutare l'attività in termini di frequenza, è necessario confrontare due momenti diversi. In questo contesto, occorre distinguere chiaramente tra unità fisiche, partizioni e dispositivi virtuali o Device Mapper; i contatori di livelli diversi non devono essere sommati indiscriminatamente. Un descrittore di file aperto di un processo non può essere associato direttamente a un contatore di dispositivo di diskstats: tra di essi si frappongono il filesystem, la cache e i livelli di mappatura. Tuttavia, insieme a /proc/pressure/io è possibile verificare se i blocchi di I/O osservabili e l’attività dei dispositivi coincidono temporalmente.

procfs in funzione: interrogazioni, monitoraggio e protezione dei dati

Per effettuare diagnosi operative ripetibili, considera le interrogazioni procfs come punti di misurazione: annota il timestamp, il contesto di sistema e l’interrogazione specifica. Molti valori sono contatori cumulativi dall’avvio; solo la differenza tra due valori divisa per l’intervallo di tempo fornisce una frequenza. Ciò vale, ad esempio, per i contatori di /proc/diskstats. Una singola interrogazione può quindi dimostrare la presenza di attività, ma non è in grado di quantificare in modo affidabile né la produttività né un deterioramento persistente.

Un sistema di monitoraggio dovrebbe rilevare, a intervalli regolari, tra l'altro, i valori memorizzati da /proc/meminfo, valori dei dispositivi da /proc/diskstats, acquisire gli stati dei processi e del sistema, nonché i segnali di stampa, qualora sia disponibile il supporto del kernel. Deve convertire i valori grezzi nelle unità appropriate, calcolare le differenze nel caso dei contatori e memorizzare gli storici. Nei container, non deve equiparare i valori globali di procfs ai limiti delle risorse del carico di lavoro: i percorsi dei processi possono essere limitati allo spazio dei nomi del PID, mentre i valori relativi alla memoria o ai dispositivi riflettono in parte quelli dell’host. Per i limiti e l’utilizzo di un gruppo sono necessarie metriche cgroup2 integrative. Solo l’andamento temporale consente di definire soglie affidabili: un valore elevato può essere normale se rientra nella finestra di carico prevista; un aumento improvviso rispetto alla propria linea di base è spesso più rilevante. Le voci procfs disponibili dipendono dal kernel in esecuzione e dalla sua configurazione.

I file diretti e gli strumenti si completano a vicenda. ps, top oppure htop sono adatti alla visualizzazione interattiva del processo; free, vmstat, iostat, pidstat, ss e sar A seconda dell'installazione, elaborano i dati per rispondere a domande specifiche. procfs rimane utile se si desidera controllare direttamente il codice sorgente del kernel o creare uno script piccolo e comprensibile. Per gli allarmi e la pianificazione delle capacità, i dati delle serie temporali rappresentano solitamente il livello più adeguato.

Anche nelle query di sola lettura si applicano dei limiti di visibilità. I diritti di accesso, le opzioni di montaggio e gli spazi dei nomi PID possono nascondere i dati di processo o limitarli a una vista del container. Viceversa, il fatto che un container disponga di un proprio montaggio /proc non implica che ogni file globale del kernel contenga esclusivamente dati del container. L’assenza di una voce di processo o un valore globale inaspettatamente elevato costituiscono quindi, in primo luogo, un’indicazione della necessità di chiarire l’ambiente di esecuzione, le opzioni di montaggio e il contesto cgroup.

Percorsi diagnostici per servizi lenti e colli di bottiglia nelle risorse

La risoluzione dei problemi inizia da un sintomo, non da un singolo valore ritenuto responsabile. Verifica quindi almeno un segnale indipendente e annota se l’osservazione riguarda l’host, una macchina virtuale o un container. In questo modo eviterai, ad esempio, di attribuire affrettatamente un carico elevato a un problema della CPU o un numero elevato di descrittori aperti a una perdita di memoria. I percorsi seguenti costituiscono una prima diagnosi orientativa e non sostituiscono i log relativi all’applicazione.

In caso di Load Average elevato, verifica innanzitutto se sono le attività in esecuzione o quelle in attesa a determinare tale valore. I dati relativi al carico rappresentano valori medi su uno, cinque e 15 minuti e tengono conto sia degli stati R che di quelli D. Pertanto, confronta i campi relativi al tempo di CPU con cautela con il carico di I/O e l'attività dei dispositivi. In particolare iowait non deve essere interpretato isolatamente come latenza della memoria.

Se l'applicazione è lenta e il valore di MemFree è basso, MemDisponibile il valore di contesto iniziale migliore. Aggiungi i dati PSI relativi alla memoria e lo stato del processo in questione, ad esempio il suo VmRSS, il numero di thread e lo stato. Per quanto riguarda la memoria e l'I/O, il PSI distingue tra some per le attività parzialmente bloccate e full per il blocco completo delle attività non idler. Se i file PSI mancano, ciò può essere dovuto alla configurazione del kernel o all'ambiente; ciò non esclude la presenza di un collo di bottiglia.

Per la diagnostica dei file e dei processi, è possibile impostare i diritti e Spazi dei nomi PID limitare la significatività. Nei container, /proc spesso descrive solo l'ambiente di processo associato. In caso di accesso negato o di directory incomplete, verifica quindi i diritti dell'utente, le opzioni di mount di procfs e il contesto del namespace prima di trarre conclusioni tecniche dall'assenza di dati.

Correggere i luoghi comuni e scegliere gli strumenti adeguati

Nell'amministrazione di Linux, quattro errori comuni portano spesso ad adottare misure sbagliate. Pochi MemFree non implica automaticamente una carenza di RAM, poiché il kernel utilizza la memoria, tra l’altro, come cache; per le nuove applicazioni, MemAvailable rappresenta una stima più significativa. Un carico elevato non indica necessariamente una saturazione della CPU, poiché vengono conteggiate anche le attività in attesa non interrompibili. Un'elevata percentuale di iowait non misura la latenza immediata di un supporto dati. Inoltre, procfs non è identico ovunque: la versione del kernel, la configurazione, l'hardware, i moduli e gli spazi dei nomi influenzano i file e i campi.

Scegli il metodo in base alla domanda. Per un’analisi puntuale delle cause, fornisce procfs Dati grezzi diretti del kernel in esecuzione. Per ottenere una panoramica rapida e leggibile, gli strumenti specializzati da riga di comando sono solitamente più efficienti. Quando contano le tendenze, gli allarmi o le decisioni relative alla capacità, è necessario un monitoraggio che ordinasse i punti di misurazione nel tempo, calcolasse le differenze tra i contatori e conservasse valori di riferimento storici. In caso di limiti di risorse per singoli servizi o container, un’analisi a livello di cgroup integra la visione globale dell’host; PSI può essere disponibile anche per singolo cgroup, se configurato opportunamente.

Si raccomanda particolare cautela nei confronti di /proc/sys. La lettura di un parametro è un’operazione diagnostica, mentre la sua modifica altera il comportamento attivo del kernel. Modifica un valore solo se ne hai compreso la causa, se il valore iniziale è stato documentato, se gli effetti sono osservabili e se è stata stabilita una procedura di ripristino. Le directory fs, vm e net classificano i parametri per argomento, ma non forniscono indicazioni universali per la messa a punto.

L'esempio drop_caches evidenzia la differenza tra intervento e ottimizzazione: la documentazione del kernel descrive l’interfaccia come non distruttiva, ma mette in guardia dai problemi di prestazioni e non la raccomanda come misura operativa regolare al di fuori di scenari di test o di debug. Una regola prudente è quindi: prima misurare, poi apportare una modifica motivata e limitata, osservare gli effetti e gli effetti collaterali e documentare la decisione.