Steal time CPU su VPS: vicini rumorosi o sovraccarico?

Che cosa misura realmente lo steal time della CPU

Lo steal time della CPU è la quota di tempo in cui la CPU virtuale era pronta per l'esecuzione, senza dover attendere nulla, mentre l'hypervisor assegnava il core fisico a un altro guest. Il lavoro era in coda. Il core era assegnato altrove. Linux conteggia separatamente questi cicli e li riporta come st. Questo permette di distinguere tra «il server è occupato» e «il server sta aspettando il proprio turno».

Questa distinzione è il motivo per cui esiste questo contatore. Il tempo che i processi impiegano sulla CPU viene riportato come us (user) o sy (system). Il tempo durante il quale un processo resta bloccato in attesa dello storage viene riportato come wa (I/O wait). Una vCPU (CPU virtuale) pronta per l'esecuzione, in coda di esecuzione, senza operazioni di I/O in sospeso e tuttavia non in esecuzione, viene riportata come st. Nessun elemento all'interno del server può modificare questo stato, perché la decisione di scheduling viene presa un livello sotto il sistema guest, sull'host.

Questo deriva direttamente da come un VPS condivide una macchina fisica tra più guest. La causa usuale è un vicino: un altro guest sullo stesso nodo sta utilizzando intensamente la CPU, quindi l'host suddivide i core tra i vari guest. Esiste anche una seconda causa, spesso trascurata. Molti provider limitano una vCPU condivisa a una frazione di un core fisico e, su diversi hypervisor, questo limite viene conteggiato come steal all'interno del guest. Un valore elevato di st indica quindi che il core non è stato assegnato al tuo guest. Non indica sempre quale guest lo abbia utilizzato.

Da dove proviene il valore di steal

Il kernel non può misurare direttamente lo steal, perché non può vedere l’host. È l’hypervisor a fornirgli questo dato. Su KVM, l’host scrive un contatore per vCPU in una pagina condivisa con il guest; il guest lo somma quando il kernel è compilato con CONFIG_PARAVIRT_TIME_ACCOUNTING, come avviene per tutti i kernel delle distribuzioni. Xen segnala lo stesso dato tramite la propria area runstate. Il valore totale arriva allo userspace in un solo punto:

head -1 /proc/stat

La riga cpu contiene dieci contatori, espressi in tick USER_HZ dall’avvio, in questo ordine: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal è l’ottavo valore dopo l’etichetta. Tutti gli strumenti seguenti, vmstat, top, mpstat e qualsiasi exporter Prometheus, leggono lo stesso campo e trasformano due campioni in una percentuale.

Una conseguenza è più importante delle altre. Se l’hypervisor non esporta il contatore, il campo resta sempre a zero e ogni strumento che lo utilizza segnala un valore 0.0, anche quando l’host è sovraccarico. KVM e Xen lo esportano. I guest su VMware e Hyper-V segnalano spesso un valore costantemente pari a zero. Verifica la piattaforma prima di considerare attendibile uno zero:

systemd-detect-virt

Il comando stampa il nome della piattaforma, ad esempio kvm, xen, vmware o microsoft, e none su bare metal. All’interno di un container restituisce invece il runtime, ad esempio lxc, docker o podman, fornendo informazioni sul container e non sulla macchina sottostante. Su kvm, uno zero è una prova concreta che l’host sta gestendo correttamente il carico del guest. Su una piattaforma che non valorizza mai il campo, uno zero non dimostra nulla: la contesa deve essere valutata misurando i tempi di esecuzione di attività reali.

Come verificare lo steal time della CPU su un VPS?

vmstat proviene dal pacchetto procps. È presente in quasi tutte le immagini VPS Ubuntu e Debian, ma può mancare in alcune immagini di container minimal. Installalo prima di farvi affidamento.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version stampa una riga simile a vmstat from procps-ng 4.0.4. Se la riga viene visualizzata, lo strumento è installato e stai leggendo contatori reali del kernel. vmstat 1 5 acquisisce quindi un campione al secondo, per cinque volte.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Nel blocco cpu sulla destra, individua la colonna st. Le versioni recenti di procps-ng stampano dopo questa colonna una colonna gu per il tempo del guest KVM. Di conseguenza, st è la seconda colonna da destra e non l'ultima. Leggi la colonna in base al nome dell'intestazione, perché questa posizione è cambiata tra le diverse release.

Due abitudini aiutano a interpretare correttamente il valore. La prima riga di dati contiene la media dal boot, quindi ignorala e leggi le righe successive. Inoltre, un solo campione non costituisce una misurazione, perché lo steal time può presentarsi a raffiche: esegui vmstat 1 60 e monitora un minuto intero prima di trarre conclusioni.

top riporta lo stesso valore nella riga di riepilogo %Cpu(s), nel campo indicato da st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Per ottenere il dettaglio per core, aggiungi sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat stampa una riga per ogni CPU, con una colonna %steal che mostra se il problema riguarda ogni vCPU o soltanto una. Per conservare lo storico necessario per un ticket di supporto, salva i campioni invece di leggerli direttamente dallo schermo:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Esegui il comando da cron nelle ore in cui sospetti il problema. Il file permetterà di passare da un'indicazione generica come «ieri sera il sistema sembrava lento» a dati precisi sui dieci minuti interessati.

Che cosa significano i valori di steal?

• Un valore 0.0 stabile. Il sistema è in buone condizioni oppure la piattaforma non segnala affatto lo steal. Prima di trarre conclusioni, verifica con systemd-detect-virt.
• Picchi di pochi punti percentuali della durata di alcuni secondi. È normale su qualsiasi nodo condiviso. Può avviarsi una build di un altro utente oppure l'host può eseguire i propri backup.
• Dall'1 al 5 percento in modo continuativo su un piano condiviso. È un valore previsto. Il prezzo riflette l'uso condiviso della CPU.
• Dal 5 al 10 percento in modo continuativo. Il rallentamento è misurabile. Inizia a raccogliere dati e confronta le stesse ore nell'arco di più giorni.
• Oltre il 10 percento per diverse ore consecutive. Il nodo è sovrasottoscritto rispetto al tuo carico di lavoro. Questo livello giustifica l'apertura di un ticket al supporto o il trasferimento a un altro nodo.

Considera queste fasce come una guida all'interpretazione, non come una specifica, perché nessun provider garantisce un determinato valore di steal nei piani condivisi. Valutale in base ai carichi che esegui. Un job batch notturno può assorbire il 15 percento di steal senza conseguenze visibili. Un servizio sensibile alla latenza lo mostra nel p99 molto prima che la media diventi preoccupante. Per questo i carichi di lavoro sensibili alla latenza, come i trading bot devono essere eseguiti su core dedicati.

Quanto ti costa il tempo sottratto?

Il calcolo è breve. Se una frazione s del tempo CPU viene sottratta, un processo che richiede una quantità fissa di CPU impiega 1 / (1 - s) volte più tempo reale. Per un processo che richiede 60 secondi di CPU:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Al 3 percento, un valore comune nei piani condivisi, il processo impiega 61.9 secondi invece di 60.0. Questo valore, da solo, di solito non porta ad aprire un ticket. Al 8 percento il tempo è di 65.2 secondi. Al 40 percento lo stesso processo richiede 100.0 secondi, e una coda che prima si svuotava inizia invece a crescere.

Sono valori calcolati, non misurazioni. Il modello presuppone un singolo thread eseguibile e una sottrazione distribuita uniformemente nell'intervallo. I servizi reali spesso risentono di un impatto maggiore rispetto a quello indicato dalla curva, perché una porzione di tempo CPU sottratta può interrompere una richiesta e il ritardo viene quindi accumulato nuovamente da tutte le operazioni in attesa di quella richiesta. Per ottenere un valore riferito al tuo ambiente invece di applicare una formula, esegui un benchmark della VPS durante un'ora con carico ridotto e poi durante un'ora intensa, registrando st per entrambe le finestre.

È steal o si tratta di qualcos’altro?

Steal può essere facilmente confuso con altri sintomi. Leggi i contatori insieme, sulla stessa riga vmstat.

• st alto mentre r e us restano bassi: l’host non ti sta assegnando il core. Questo è steal.
• r molto al di sopra del numero di vCPU, con us alto e st vicino a zero: stai eseguendo più attività di quante ne possano gestire le tue CPU. Confronta r con l’output di nproc. Questa è una sovrascrizione delle risorse causata da te, non da un vicino.
• wa alto con st vicino a zero: le attività sono bloccate sullo storage. Si tratta di un problema diverso, che richiede una correzione diversa.
• Load average alto mentre st e us sono entrambi bassi: il valore di load conta anche le attività non interrompibili. Questo indica in genere un dispositivo bloccato o un mount di rete non responsivo, non un problema di CPU.

I piani burstable richiedono una nota separata. Forniscono un saldo di crediti che aumenta quando il carico è basso e diminuisce quando il carico è elevato. Quando i crediti terminano, il provider limita la velocità al livello baseline. Su alcune piattaforme questo throttling viene riportato come steal. Su altre non è visibile dall’interno e si ricevono semplicemente meno cicli al secondo. Leggi la descrizione del piano prima di attribuire il problema a un vicino.

Perché un container non segnala steal time

Lo steal è una proprietà della macchina virtuale, non del container eseguito al suo interno. Un container Docker sul proprio VPS condivide il /proc dell'host, quindi un valore st letto al suo interno corrisponde allo steal del VPS, che è il dato necessario. La virtualizzazione basata su container, venduta come VPS, si comporta diversamente. Quando è presente lxcfs, il valore /proc/stat all'interno del container viene sintetizzato a partire dai dati contabili del cgroup e lo steal è zero per costruzione. Uno stack di monitoraggio che raccoglie i dati soltanto dall'interno può mostrare uno zero costante e apparentemente normale, mentre la macchina fisica sottostante è sovraccarica.

All'interno di un container, il contatore con lo stesso significato è il throttling della quota CPU. Con cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled conta i periodi di applicazione dei limiti in cui il gruppo ha raggiunto la quota CPU e throttled_usec somma il tempo durante il quale è rimasto sospeso. Un valore nr_throttled in aumento indica che il processo era pronto per essere eseguito ma non era in esecuzione: l'esperienza è la stessa dello steal, ma la causa è un limite impostato dall'utente. Controllare i propri limiti prima di attribuire la causa all'host, soprattutto se esegui i tuoi servizi in Docker su un VPS con limiti CPU nel file compose. La virtualizzazione a più livelli aggiunge un altro punto in cui il tempo può andare perso, perché una VM all'interno del VPS subisce sia lo steal del VPS sia il proprio ritardo di scheduling. Tenerne conto se usi la virtualizzazione annidata su un VPS.

Cosa fare in caso di steal persistente

Nessuna impostazione nel guest risolve lo steal, perché la decisione viene presa dallo scheduler che opera all’esterno del guest. Le opzioni effettive sono quattro.

Raccogli prima le evidenze. Registra i timestamp in UTC, la durata di ogni episodio, la frequenza con cui si ripete e se mpstat mostra un solo vCPU interessato oppure tutti. Una settimana di campioni registrati vale più di uno screenshot.

Apri un ticket con questi dati. Poni due domande dirette: il nodo è sovrallocato durante queste finestre temporali? È possibile spostare la mia istanza? Incolla l’output di vmstat e gli orari esatti. I provider intervengono quando il problema è riproducibile; un ticket che si limita a segnalare che il server è lento riceverà una risposta in cui vengono richiesti questi dati. La quantità di attività che puoi delegare è una delle differenze pratiche tra un VPS gestito e uno non gestito.

Chiedi una migrazione. Spostare un guest su un nodo meno carico è un’operazione ordinaria per un provider e di solito richiede un breve riavvio. È la correzione che non comporta costi e risolve il caso comune, in cui su un nodo si trovano contemporaneamente diversi guest vicini pesanti.

Elimina la contesa acquistando risorse dedicate. Un piano con vCPU dedicati riserva core fisici alla tua istanza, quindi il contatore resta a zero. Il costo mensile è maggiore, ma è la scelta corretta per un carico di lavoro che non può tollerare questa variabilità. Se non è ancora sufficiente, oppure vuoi riservare anche la larghezza di banda della memoria, il passo successivo è un server dedicato invece di un VPS.

Nel frattempo, riduci l’impatto dello steal. Esegui meno thread worker rispetto al numero di vCPU disponibili, perché i thread che non riescono a ottenere un core aggiungono soltanto cambi di contesto. Sposta i processi batch nelle ore in cui il nodo è meno carico, come ora puoi verificare dai tuoi log. Misura quindi di nuovo con lo stesso comando e nelle stesse ore, per stabilire se la modifica ha funzionato invece di procedere per supposizioni.

FAQ

Qual è un valore normale di CPU steal time su un VPS?

Su un piano condiviso, brevi picchi e un valore sostenuto inferiore a circa 5 percento sono normali, perché la CPU condivisa implica che l'host distribuisca i core fisici tra più guest. Un valore a due cifre mantenuto per diverse ore non è normale e giustifica l'apertura di un ticket. Su un piano con vCPU dedicata il valore atteso è 0.0; qualsiasi altro valore indica un problema da segnalare. Valuta il numero in rapporto al tuo carico di lavoro: un job batch notturno può tollerare steal time che un'API sensibile alla latenza non può tollerare.

Un piano più grande risolve un valore elevato di steal time?

Non da solo. Aggiungere vCPU sullo stesso nodo condiviso significa avere più CPU virtuali in competizione per gli stessi core fisici contesi, quindi la percentuale può rimanere esattamente invariata. Per eliminare steal time servono un'allocazione di CPU dedicata oppure la migrazione a un nodo meno carico. Una quota maggiore di una macchina sovraccarica resta comunque una quota di una macchina sovraccarica.

Perché il mio VPS mostra 0 steal time anche se è chiaramente lento?

Le cause comuni sono due. L'hypervisor potrebbe non esportare affatto il contatore, come avviene di norma sulle piattaforme VMware e Hyper-V; in questo caso il campo rimane a zero indipendentemente da ciò che accade sull'host. Esegui systemd-detect-virt per verificare quale piattaforma stai utilizzando. In alternativa, il collo di bottiglia si trova altrove: controlla wa per le attese sullo storage, confronta r con nproc per verificare il sovraccarico del tuo sistema e leggi /sys/fs/cgroup/cpu.stat nei container per individuare il throttling imposto dalle quote.

Posso ridurre lo steal time dall'interno del server?

Non puoi modificare la pianificazione dell'host dall'interno del guest. Puoi soltanto ridurre l'impatto del problema. Esegui meno thread worker rispetto al numero di vCPU disponibili, così meno attività rimane nella run queue in attesa di un core che non si libera. Sposta i job batch nelle ore in cui il nodo è meno carico. Memorizza i risultati nella cache, così un numero inferiore di richieste richiede CPU. Le modifiche che eliminano effettivamente lo steal time, cioè la migrazione a un altro nodo o l'assegnazione di core dedicati, dipendono dal provider.