1 31/10/2026 9 min

Quando CPULimit ha senso davvero

CPULimit è un piccolo strumento da usare quando un processo consuma troppa CPU e vuoi mettergli un freno senza riscrivere l’applicazione, senza cambiare scheduler e senza intervenire sul kernel. In pratica, non “ottimizza” il programma: gli impone una soglia di utilizzo, lasciando respirare il resto del sistema. È utile in tre casi tipici: macchine condivise, test di carico controllati e contenzione temporanea di un servizio che sta saturando una CPU in attesa di una correzione vera.

Va chiarito subito un punto: CPULimit non è un sostituto del tuning applicativo. Se un servizio va fuori controllo per bug, loop, query lente o thread impazziti, la limitazione è un tampone. Ti compra tempo, ma non elimina la causa. Per questo conviene usarlo come misura reversibile, con monitoraggio prima e dopo, e con un piano di rollback già pronto.

Come funziona: non blocca, rallenta

CPULimit lavora in modo semplice: osserva l’uso CPU di uno o più processi e invia segnali di stop e ripresa quando la soglia viene superata. Il risultato pratico è una riduzione dell’utilizzo medio, non un tetto rigido al millisecondo. Per questo il comportamento può variare un po’ in base al carico, al numero di core e alla natura del processo.

Su sistemi multi-core bisogna fare attenzione: un processo che usa più thread può sembrare “oltre il 100%” se misurato rispetto a un singolo core. CPULimit ragiona sulla percentuale di CPU che vuoi concedere al processo, ma il risultato percepito cambia a seconda del contesto. In altre parole: non aspettarti una precisione da hard limit di cgroup o da quota del kernel; aspettati un contenimento pratico, spesso sufficiente per tenere in piedi il sistema.

Installazione su Debian, Ubuntu, RHEL e derivate

Su molte distribuzioni CPULimit è già disponibile nei repository standard. L’installazione è banale, ma conviene verificare prima il nome del pacchetto perché può cambiare leggermente tra distro. Se sei su Ubuntu o Debian, di solito basta questo:

sudo apt update
sudo apt install cpulimit

Su sistemi basati su RHEL, Rocky, AlmaLinux o CentOS Stream, il nome del pacchetto può essere presente nei repository standard o in EPEL, a seconda della release. Il flusso corretto è controllare prima la disponibilità e poi installare:

sudo dnf search cpulimit
sudo dnf install cpulimit

Se il pacchetto non compare, non forzare installazioni improvvisate da sorgenti non verificate: prima cerca il repository corretto della tua distribuzione. In ambienti di produzione, la preferenza resta sempre per pacchetti firmati e tracciabili.

Verifica rapida dopo l’installazione

Dopo l’installazione, il controllo minimo è sapere dove si trova il binario e leggere l’help. È un passaggio piccolo, ma utile per confermare che il pacchetto sia stato installato davvero e che la sintassi disponibile sia quella attesa:

which cpulimit
cpulimit --help

Se il primo comando restituisce un percorso come /usr/bin/cpulimit, sei a posto. Se il secondo mostra le opzioni disponibili, hai anche conferma che l’eseguibile è funzionante. Se invece il binario non compare, il problema è quasi sempre a monte: pacchetto non installato, PATH alterato o installazione non andata a buon fine.

Limitare un processo già avviato

Il caso più comune è intervenire su un processo che sta già consumando troppa CPU. Ti serve il PID. Puoi ottenerlo con strumenti classici come ps, pgrep o un monitor interattivo. In ambienti operativi, pgrep è spesso la scelta più rapida perché evita parsing inutili.

pgrep -a nginx
pgrep -a php-fpm
pgrep -a java

Una volta identificato il PID, applica il limite. Ad esempio, per contenere un processo al 30% di CPU:

sudo cpulimit -p 1234 -l 30

Qui -p indica il PID e -l la percentuale massima. Se il processo è legato a un servizio web o a un worker, tieni d’occhio latenza e code applicative: un limite troppo aggressivo può ridurre l’impatto sulla CPU ma aumentare i tempi di risposta.

Per verificare l’effetto, osserva il consumo con top, htop o strumenti di monitoraggio già presenti. Il comportamento atteso è una discesa dell’uso CPU del processo limitato e, se il servizio era la causa del problema, un miglioramento della reattività del resto della macchina.

Lanciare un comando sotto limite fin dall’avvio

Puoi usare CPULimit anche per avviare direttamente un comando. È utile nei test o quando vuoi limitare un job batch senza creare wrapper complessi. La sintassi è semplice:

cpulimit -l 40 -- tar -czf backup.tar.gz /var/www/html

In questo esempio il comando tar viene eseguito con una soglia del 40%. Il vantaggio è immediato: non devi cercare il PID dopo l’avvio, e il limite vale da subito. Il rovescio della medaglia è che il comando gira più lentamente; per job lunghi può essere perfettamente accettabile, per task sensibili ai tempi no.

Se il processo genera figli, il comportamento dipende da come viene lanciato e da come CPULimit riesce a seguirlo. Nei casi complessi conviene testare prima in ambiente non critico, perché i processi che fanno fork o che cambiano identità possono richiedere attenzione extra.

Usarlo con systemd: attenzione al processo giusto

Su sistemi moderni molti servizi sono gestiti da systemd. Questo non cambia la logica di CPULimit, ma cambia il modo in cui identifichi il processo da limitare. Non sempre il PID principale è quello che consuma davvero CPU: a volte il carico è nei worker figli o in processi secondari del servizio.

Il primo passo è capire quali PID appartengono al servizio. Puoi usare:

systemctl status nome-servizio
systemd-cgls

Se il servizio ha più processi, valuta quale componente sta saturando la CPU prima di applicare il limite. Limitare il PID sbagliato può dare l’illusione di aver risolto, ma lasciare il problema intatto. In alternativa, se l’obiettivo è una contenzione più robusta e ripetibile, spesso è meglio ragionare su cgroup e quote native di systemd invece di affidarsi solo a CPULimit.

Avvio automatico al boot con systemd

Se il limite deve essere applicato sempre allo stesso servizio, puoi creare un’unità systemd dedicata. È una soluzione pratica, ma va trattata come change controllato: fai un backup del file, prova in finestra di manutenzione e tieni pronto il rollback. Il raggio d’azione è il servizio interessato, non l’intero sistema, ma un errore di configurazione può impedirne l’avvio.

Un esempio semplice consiste nel creare un servizio che esegua CPULimit in parallelo al processo target. La struttura dipende dal servizio e dal modo in cui si avvia, ma l’idea è questa:

[Unit]
Description=CPU limit for my service
After=multi-user.target [Service]
Type=simple
ExecStart=/usr/bin/cpulimit -p 1234 -l 50
Restart=always [Install]
WantedBy=multi-user.target

Questo esempio è volutamente minimale e non va copiato alla cieca in produzione: il PID 1234 è statico, quindi è adatto solo a test o a casi molto controllati. In un’implementazione reale devi agganciare il processo in modo dinamico, oppure scegliere una strategia più robusta. Dopo ogni modifica, verifica lo stato con systemctl status e i log con journalctl -u nome-servizio.

CPULimit non è la stessa cosa di nice, renice o cgroups

Capita spesso di confondere strumenti diversi. nice e renice agiscono sulla priorità di scheduling, non impongono un tetto di CPU. Possono aiutare a far cedere tempo macchina a un processo meno urgente, ma non garantiscono che quel processo si fermi a una percentuale precisa. CPULimit invece cerca proprio di contenerne l’uso medio.

I cgroup e le quote di systemd sono un’altra categoria ancora: più strutturati, più integrati nel sistema, spesso preferibili in ambienti server. Se devi gestire limiti stabili e ripetibili su servizi importanti, le quote native sono in genere una base migliore. CPULimit resta comunque comodo quando vuoi una misura rapida, poco invasiva e immediata.

Diagnosi quando il limite non sembra funzionare

Se applichi CPULimit e non vedi il risultato atteso, le cause più probabili sono poche. La prima è aver limitato il PID sbagliato. La seconda è che il processo reale sia figlio di un altro eseguibile o venga rigenerato da un supervisor. La terza è che il carico venga distribuito su più thread o più processi, rendendo meno evidente il calo su un singolo PID.

Per falsificare rapidamente queste ipotesi, controlla il tree dei processi, osserva il consumo per thread se disponibile e verifica che CPULimit stia effettivamente girando con il PID corretto. Un controllo utile è:

ps -fp 1234
pstree -ap 1234
top -H -p 1234

Se il processo viene ricreato da un servizio o da un watchdog, il limite può sparire al riavvio del worker. In quel caso la soluzione non è rilanciare a mano CPULimit ogni volta, ma integrare il controllo nel flusso operativo corretto o passare a una quota più nativa e persistente.

Uso pratico in emergenza: contenere senza spegnere

Uno degli usi più sensati è l’emergenza: il server non è ancora morto, ma un processo sta divorando CPU e rischia di far saltare tutto il resto. Qui CPULimit può essere un tampone efficace. L’obiettivo non è rendere il servizio perfetto, ma guadagnare margine per analizzare log, metriche e causa radice senza tagliare completamente l’erogazione.

In questo scenario il flusso corretto è: identificare il colpevole, applicare un limite moderato, verificare che la saturazione totale scenda, poi indagare. Se il servizio è critico, annota sempre il cambio fatto, l’orario e il motivo. Quando il problema è risolto, rimuovi il limite e conferma che il comportamento torni normale.

Rollback e rimozione del limite

Il rollback è semplice: se hai avviato CPULimit in foreground, interrompi il processo; se gira in background, termina il relativo PID; se lo hai integrato in una unità systemd, disabilita o modifica l’unità e ricarica la configurazione. Il punto non è solo togliere il freno, ma farlo in modo ordinato per non lasciare servizi appesi o stati incoerenti.

pkill cpulimit
sudo systemctl daemon-reload
sudo systemctl restart nome-servizio

Prima di rimuovere il limite, verifica che la causa del sovraccarico sia stata affrontata. Se il problema persiste e il limite viene tolto troppo presto, torni esattamente al punto di partenza, spesso con un impatto peggiore perché nel frattempo il carico si è accumulato.

Quando evitare CPULimit

Evitalo quando ti serve un controllo rigoroso delle risorse, quando il servizio è mission-critical e deve rispettare quote stabili, oppure quando il collo di bottiglia non è la CPU ma disco, memoria, lock o rete. In questi casi rischi di curare il sintomo sbagliato. Se un processo è bloccato su I/O, limitarne la CPU non risolve la latenza; se manca RAM, il problema può peggiorare per effetto collaterale.

In sintesi, CPULimit è uno strumento utile e onesto: fa una cosa sola, e la fa in modo abbastanza semplice da essere usato bene anche sotto pressione. Proprio per questo conviene trattarlo come una leva tattica, non come architettura definitiva.