Come individuare script che consumano CPU e RAM su server Linux con il comando "htop"

Sul server Linux, il comando htop rappresenta uno degli strumenti più pratici per monitorare in tempo reale gli script che consumano eccessivamente CPU e RAM. Analizzando le colonne CPU%, MEM%, PID, USER, TIME+ e COMMAND nella schermata di htop, puoi capire quale processo PHP, Python, Node.js, cron, database o di sistema sta rallentando il server; successivamente, puoi controllare il proprietario, il percorso del file e lo scopo del processo, intervenendo in modo sicuro.

Che tu utilizzi hosting condiviso, VPS, VDS o un server dedicato, gran parte dei rallentamenti improvvisi deriva da script non controllati. Ad esempio, un plugin WordPress difettoso, un file PHP bloccato in un ciclo infinito, un cron job troppo pesante, una query database non ottimizzata o un file web compromesso possono portare l’utilizzo della CPU al 100% in pochi minuti. Quando il consumo di RAM aumenta, i servizi possono bloccarsi, le connessioni MySQL cadere, i siti web restituire errori 503 oppure il kernel Linux terminare alcuni processi tramite OOM Killer.

Questa guida ti mostra passo passo dall’installazione di htop, alla lettura della schermata, fino all’identificazione degli script che consumano CPU e RAM, come risalire al percorso del file tramite PID e come intervenire in modo sicuro. Inoltre, troverai consigli per il controllo sicurezza, verifica cron, analisi log e ottimizzazione per prevenire il problema. Se sul tuo server riscontri spesso limiti di risorse, valuta anche l’infrastruttura e consulta le pagine Pacchetti server VPS e web hosting ad alte prestazioni per scegliere la soluzione più adatta.

Cos’è htop e perché è più comodo del comando top?

htop è uno strumento interattivo per il monitoraggio dei processi in ambiente Linux. Simile al tradizionale comando top, offre però un’interfaccia più leggibile, indicatori colorati delle risorse, sorting veloce, ricerca, filtri e funzioni avanzate di gestione dei processi. Per questo, durante la diagnosi rapida su server live, htop è il punto di riferimento per molti sysadmin.

Con htop puoi visualizzare in tempo reale:

• Percentuale di CPU utilizzata da ogni processo
• Percentuale e quantità di RAM utilizzata da ciascun processo
• Numero PID del processo
• Utente Linux che esegue il processo
• Comando/script eseguito
• Durata di esecuzione e priorità
• Load average, RAM totale, swap e uso dei core CPU

In particolare, in ambienti hosting dove girano più siti, utenti o servizi sullo stesso server, vedere solo il consumo globale non basta: è fondamentale scoprire quale utente, sito, cron job o script sta causando il problema. Il comando htop su Linux fornisce una diagnosi immediata.

Installazione di htop: comandi per ogni distribuzione

Molte distribuzioni Linux moderne non includono htop di default. Se disponi di permessi root o sudo, puoi installarlo rapidamente. Prima della installazione, aggiorna la lista dei pacchetti per evitare errori, specialmente su server appena configurati.

Installazione htop su server Ubuntu e Debian

Su server Ubuntu o Debian, usa questi comandi:

sudo apt update

sudo apt install htop -y

Dopo l’installazione, avvia htop semplicemente digitando htop. Se non hai permessi sudo, chiedi assistenza al provider. Su VPS gestiti, di solito hai accesso root.

Installazione su AlmaLinux, Rocky Linux, CentOS e RHEL

Su sistemi RHEL, il gestore pacchetti può essere dnf o yum secondo la versione:

sudo dnf install htop -y

Sui vecchi CentOS potrebbe essere necessario il repository EPEL:

sudo yum install epel-release -y

sudo yum install htop -y

Se l’installazione va a buon fine, digitando htop in terminale compare la schermata colorata di monitoraggio. Se sei alle prime armi con la gestione server, la guida guida ai comandi Linux è un ottimo punto di partenza.

Come leggere la schermata di htop: significato delle colonne

Quando apri htop, la parte superiore mostra i core CPU, RAM, swap, numero processi, thread, load average e uptime. In basso trovi la lista dei processi attivi. Le colonne più utili per la diagnosi sono:

È importante sapere che un picco temporaneo di CPU non è sempre un problema. Backup, ottimizzazione immagini, pulizia cache o picchi di traffico possono causare un aumento temporaneo. Il vero problema è un processo che resta alto per minuti, load average che supera il numero di core, e servizi web che non rispondono.

Come individuare script che consumano CPU con htop

Per trovare gli script che saturano la CPU, nella schermata di htop puoi selezionare la colonna CPU% con F6 oppure, se il terminale lo permette, cliccare sul titolo della colonna. In cima vedrai i processi che stanno utilizzando più CPU in quel momento.

Passo 1: Ordina per CPU%

Ordina i processi per utilizzo CPU. Se vedi ad esempio php-fpm, php, python3, node, java, mysqld o bash sempre ai primi posti, annota questi processi. Su sistemi multi-core, un processo può arrivare oltre il 100% (es. 200% o 400%) perché sfrutta più core contemporaneamente.

Passo 2: Annotare PID e USER

Segna il numero PID e l’utente del processo sospetto. Se PID 24819, USER “siteuser” e COMMAND mostra php /home/siteuser/public_html/wp-cron.php, il problema è probabilmente legato al cron di WordPress su quel sito. Se la colonna COMMAND è corta, attiva la visualizzazione completa o usa il comando ps per maggiori dettagli.

Passo 3: Visualizza il comando reale del processo

Per vedere il comando completo relativo a un PID:

ps -fp PID

Esempio:

ps -fp 24819

Di solito mostra da quale file viene eseguito lo script. Se appare php /home/utente/public_html/index.php, può essere una richiesta web. Se invece compare php /home/utente/public_html/wp-content/plugins/plugin-sospetto/task.php, il problema può essere causato da un plugin.

Passo 4: Controlla percorso file e file aperti

Per vedere quali file usa un processo, il comando lsof è utile:

lsof -p PID

Mostra file, librerie, log e connessioni aperte dal processo. In ambienti hosting, così puoi scoprire quale directory del sito è coinvolta. Se vedi un file PHP dal nome strano in /home/example/public_html/wp-content/uploads, potrebbe essere un segnale di compromissione. In tal caso non basta terminare il processo; bisogna pulire i file, cambiare password, aggiornare plugin e fare una scansione di sicurezza. Per configurare SSL e connessioni sicure, consulta anche soluzioni di certificato SSL.

Come individuare script che consumano RAM con htop

I problemi di RAM sono spesso più insidiosi di quelli CPU. Quando la CPU sale, il rallentamento è percepibile; se la RAM si esaurisce, i servizi possono chiudersi in modo inatteso, swap viene usato intensivamente e il server rallenta globalmente. Ordina la colonna MEM% per trovare i processi che consumano più memoria.

Comprendere MEM%, RES e Swap

htop mostra MEM% di default; a volte trovi anche VIRT, RES e SHR. Per l’analisi RAM, il valore RES è il più affidabile, perché indica la memoria fisica realmente utilizzata dal processo. VIRT rappresenta la memoria virtuale assegnata, ma non va interpretata come RAM reale.

Su un VPS con 4 GB di RAM, un singolo processo PHP che usa 900 MB di RES è anomalo. Un’app Node.js che passa da 200 MB a 1.5 GB suggerisce un memory leak. Per MySQL/MariaDB, RAM alta può essere dovuta al caching; valuta query, buffer e RAM totale insieme.

Cause tipiche nei processi che consumano RAM

• Script PHP, Python, Node.js bloccati in loop infinito
• Caricamento in memoria di grandi file CSV, XML o JSON
• Plugin o funzioni WordPress non ottimizzate
• Elaborazione immagini, generazione PDF o conversione video
• Assenza di cache e ripetizione di query pesanti
• Traffico bot o attacchi che attivano molti script contemporaneamente
• Processi background con perdita di memoria

Terminare il processo con kill risolve solo temporaneamente. La soluzione permanente richiede analisi del codice, input e motivi del mancato rilascio della memoria.

Funzioni di ricerca, filtro e vista ad albero in htop

Se il server gestisce centinaia di processi, la ricerca manuale diventa difficile. htop offre scorciatoie utili: F3 per cercare, F4 per filtrare, F5 per la vista ad albero. La vista ad albero è essenziale per vedere la relazione padre-figlio, ad esempio processi php-fpm lanciati da nginx o Apache, script cron o servizi Node.js gestiti da supervisor.

Esempi pratici di filtro

• Cerca php per visualizzare solo processi PHP.
• Cerca python per isolare script Python.
• Cerca wp-cron per controllare cron di WordPress.
• Cerca node per analizzare applicazioni Node.js.
• Filtra per nome utente per vedere i processi di uno specifico account hosting.

I filtri sono indispensabili su server multi-utente: se ospiti 30 siti, la colonna USER e il percorso del comando aiutano a identificare velocemente l’account problematico. Per semplificare la gestione dei domini, consulta Verifica del dominio e registrazione.

Piano di intervento sicuro su PID sospetti

Quando identifichi un processo che consuma troppe risorse, può essere tentante usare subito kill -9. Ma questa scelta rischia perdita dati, scritture incomplete o incoerenza dei servizi. Meglio seguire un piano sicuro.

1. Documenta il processo

Annota PID, USER, COMMAND, CPU%, MEM% e durata. Se possibile, salva uno screenshot di htop. Queste informazioni aiutano nelle analisi future, e sono utili per spiegare tecnicamente il problema a clienti o colleghi.

2. Verifica il percorso file del processo

Controlla output di ps -fp PID e lsof -p PID. Se il file è nella web root, analizza i log applicativi. Per WordPress usa wp-content/debug.log, per il server web access log ed error log, per PHP-FPM slow log.

3. Prova prima la terminazione gentile

Se il processo è davvero fuori controllo, prova prima a terminare con:

kill PID

Attendi qualche secondo e verifica se il processo si chiude in htop. Se persiste e danneggia il sistema, solo allora usa:

kill -9 PID

kill -9 termina il processo senza consentirgli operazioni di pulizia, quindi va usato con cautela su database, scritture file o backup.

4. Se il processo si riavvia, cerca il trigger

Se il processo si riavvia subito dopo la terminazione, può essere attivato da cron, systemd, supervisor, richieste web o bot. Controlla crontab -l per cron, systemctl status per servizi, access log per traffico web. Se il problema è dovuto a wp-cron su WordPress, valuta cron reale e politiche di cache.

Combinare htop con i log di sistema

htop mostra cosa consuma risorse; i log ti aiutano a capire perché. Se usi solo htop senza analizzare i log, la diagnosi resta incompleta. Ad esempio, un processo php-fpm può usare il 180% di CPU, ma solo i log access ti dicono quale URL o bot lo ha attivato.

Log utili da analizzare:

• Access log del server web: mostra le URL più richieste.
• Error log del server web: evidenzia errori PHP, permessi file, errori 500.
• PHP-FPM slow log: identifica script PHP lenti.
• MySQL slow query log: mostra le query SQL più pesanti.
• Auth log o secure log: registra login sospetti.
• Cron log: traccia quando partono i job programmati.

Se il PID che consuma CPU corrisponde a richieste massicce di /wp-admin/admin-ajax.php negli access log, il problema può essere un plugin, bot o codice AJAX mal progettato. In questi casi valuta firewall, rate limiting, cache e ottimizzazione plugin. Per un approccio più completo alla performance consulta Ottimizzazione della velocità del sito web.

Come distinguere carico normale da carico problematico

Un consumo elevato di risorse non è sempre una crisi. Considera hardware, traffico, tipo di applicazione e operazioni di manutenzione. Su VPS a 2 core, load average a 6-8 per lungo tempo indica un collo di bottiglia; su dedicato a 16 core è normale. Interpreta sempre il load average in funzione dei core.

Queste indicazioni aiutano a distinguere tra situazione normale e reale crisi di performance. Sui siti e-commerce, promozioni, pagamenti o aggiornamenti stock possono causare picchi temporanei. Se però l’esperienza utente ne risente, valuta ottimizzazione applicativa e aumento risorse server.

Sicurezza: uno script che consuma risorse può essere dannoso?

Uno script che satura CPU o RAM non è sempre innocuo. In siti compromessi, gli attaccanti possono eseguire script per spam, mining crypto, proxy, botnet DDoS o backdoor. htop mostra processi strani sotto utenti inattesi, nomi file casuali, eseguibili in /tmp o PHP in /uploads: tutti segnali di rischio.

Segnali sospetti

• Nomi file casuali o incomprensibili nella colonna COMMAND
• File eseguiti da /tmp, /dev/shm o /uploads
• Processi perl, python o bash non previsti
• Processi con molte connessioni esterne
• Stesso utente che avvia molti processi in poco tempo
• File web modificati recentemente senza autorizzazione

Prima di terminare il processo, salva le prove (output dei comandi). Poi controlla i permessi file, isola i file sospetti, cambia tutte le password di pannello e CMS, aggiorna plugin e temi, esegui scansioni di sicurezza. Per ridurre i rischi, attiva l’autenticazione a due fattori nei pannelli amministrativi e limita i permessi di scrittura non necessari.

Best practice per prevenire problemi di performance su Linux

Individuare il problema è fondamentale, ma lo è ancora di più evitare che si ripresenti. Ecco alcune misure che riducono drasticamente i blocchi causati da CPU e RAM:

• Configura PHP memory_limit, max_execution_time e pm.max_children in base alle risorse disponibili.
• Usa sistemi di cache su WordPress, Joomla o software custom.
• Elimina plugin, temi e moduli inutili.
• Ottimizza le query pesanti tramite MySQL slow query log.
• Distribuisci i cron job su intervalli diversi, non tutti nello stesso minuto.
• Proteggi da bot con rate limit, robots.txt e regole firewall.
• Ruota i log applicativi, monitora l’impatto di log troppo grandi su RAM e disco.
• Controlla i dati di monitoraggio server in modo regolare, non solo in caso di crisi.

Se nonostante l’ottimizzazione l’utilizzo risorse resta alto, il problema può essere anche di scala: traffico aumentato, applicazione cresciuta, piano hosting non più adeguato. In questi casi opta per VPS scalabile, RAM aggiuntiva, dischi NVMe più veloci o server dedicato. Per scegliere, confronta Pacchetti di Hosting e soluzioni di server aziendale.

Scenario pratico: spike CPU su sito WordPress

Ecco un caso reale: su un VPS con 4 core e 8 GB RAM girano vari siti WordPress. Gli utenti lamentano lentezza e errori 502. htop mostra load average a 12, tutti i core saturi, e molti processi php-fpm dello stesso utente ai primi posti.

Filtra per utente con F4. Segna il PID dei processi che consumano CPU. ps -fp PID mostra un worker php-fpm; lsof -p PID rivela accesso al file /home/site/public_html/wp-content/plugins/example-importer/import.php. Nei log access, in corrispondenza del problema, si vedono richieste ripetute verso questo file tramite AJAX.

La soluzione: interrompi l’import, disattiva il cron del plugin, suddividi l’importazione dati in batch, modifica max_execution_time di PHP e imposta cron reale anziché wp-cron. Così il load average scende da 12 a 1.8, la CPU torna normale e il sito risponde più velocemente. Questo esempio dimostra quanto sia efficace combinare htop con ps, lsof e analisi log.

Errori comuni nell’utilizzo di htop

• Terminare solo il processo in cima senza indagare la causa.
• Interpretare VIRT come consumo reale di RAM.
• Considerare sempre anomalo il caching RAM di MySQL.
• Usare kill -9 come prima scelta.
• Accusare applicazione o utente senza controllare i log.
• Valutare load average senza considerare il numero di core.
• Non verificare l’integrità dei file in caso di sospetta compromissione.

Evitare questi errori riduce i tempi di downtime e il rischio di perdita dati per interventi errati. In amministrazione sistemi, una diagnosi corretta è spesso più preziosa della rapidità d’intervento.

Domande frequenti

A cosa serve il comando htop su server Linux?

htop mostra in tempo reale processi attivi, consumo CPU e RAM, utente, PID e comando. Permette di identificare rapidamente script che saturano risorse.

Come trovo uno script che consuma CPU con htop?

Ordina i processi per CPU% in htop, annota PID e USER dei processi che restano a lungo in cima. Poi usa ps -fp PID e lsof -p PID per scoprire il percorso del file e cosa sta eseguendo.

Per l’analisi RAM, è meglio MEM% o VIRT?

MEM% e soprattutto RES sono più significativi. VIRT indica memoria virtuale allocata e non riflette necessariamente il reale consumo di RAM.

Va terminato subito un processo che consuma risorse con kill -9?

No, di solito è meglio documentare prima il processo, controllare il percorso file e provare kill PID. kill -9 va usato solo se il processo non si chiude e mette a rischio il server.

Un alto consumo CPU in htop è sempre segno di attacco?

No. Backup, import, cache o traffico intenso possono causare picchi. Ma script con nomi casuali, eseguiti da /tmp o /uploads, e processi di utenti inattesi meritano indagini di sicurezza.

In sintesi, il comando htop su Linux è uno strumento rapido ed efficace per scoprire script che saturano CPU e RAM. Per una diagnosi completa, abbina htop ad analisi PID, output lsof, verifica cron e log. Se i problemi di risorse si ripresentano, valuta sia l’ottimizzazione software che la capacità infrastrutturale; confronta senza pressione commerciale le soluzioni Hosting, VPS e SSL di Hostragons per scegliere la struttura migliore per il tuo progetto.