Miglioramento della misurazione del throttling della CPU

È passato un anno e mezzo da quando abbiamo implementato la funzionalità di throttling della CPU del container con riconoscimento delle limitazioni per IBM Turbonomic e ha catturato parecchia attenzione, per una buona ragione. Come illustrato nel nostro primo post sul blog, impostare un limite di CPU errato sta silenziosamente compromettendo le prestazioni dell'applicazione e impedendole di funzionare come previsto.

Turbonomic visualizza le metriche di throttling e, cosa ancora più importante, tiene conto del throttling quando consiglia il dimensionamento del limite della CPU. Non solo possiamo smascherare questo killer silenzioso delle prestazioni, ma Turbonomic prescriverà il valore limite della CPU per minimizzare il suo impatto sulle prestazioni della tua applicazione containerizzata.

In questo nuovo post, parleremo di un miglioramento significativo nel modo in cui misuriamo il livello di throttling. Prima di questo miglioramento, il nostro indicatore di limitazione veniva calcolato in base alla percentuale di periodi di limitazione. Con tale misurazione, il throttling è stato sottostimato per le applicazioni con un limite di CPU basso e sovrastimata per quelle con un limite di CPU alto. Ciò ha portato a valutare in modo troppo aggressivo le applicazioni con limiti elevati, poiché abbiamo orientato il nostro processo decisionale verso applicazioni con limiti bassi per ridurre al minimo la limitazione e garantirne le prestazioni.

In questo recente miglioramento, misuriamo il throttling in base alla percentuale di tempo di throttling. In questo post, ti mostreremo come funziona questa nuova misurazione e perché correggerà sia la sottostima che la sovrastima menzionata sopra:

• Breve rivisitazione del throttling della CPU

• Il metodo vecchio/distorto: misurazione del throttling basata sul periodo
• Il metodo nuovo/imparziale: misurazione del throttling basata sul tempo
• Risultati del benchmarking
• Rilascio

Se guardi questo video dimostrativo, puoi vedere un'illustrazione simile del throttling. Si tratta di un'app container a thread singolo con un limite di CPU di 0,4 core (o 400 m). Il limite di 400 m in Linux si traduce in una quota CPU cgroup di 40 ms ogni 100 ms, che è il periodo di applicazione della quota predefinito in Linux adottato da Kubernetes. Ciò significa che l'app può utilizzare solo 40 ms di tempo della CPU in ogni periodo di 100 ms prima di essere limitata per 60 ms. Questa operazione si ripete quattro volte per un'attività da 200 ms (come quella mostrata di seguito) e infine viene completata nel quinto periodo senza throttling. Complessivamente, l'attività da 200 ms richiede 100 * 4 + 40 = 440 ms per essere completata, più del doppio del tempo effettivo necessario per la CPU:

Linux fornisce le seguenti metriche relative al throttling, che cAdvisor monitora e invia a Kubernetes:

Scorri per visualizzare la tabella completa

Come accennato all'inizio, siamo soliti misurare il livello di throttling come percentuale di periodi eseguibili limitati. Nell'esempio precedente, sarebbe 4 / 5 = 80%.

Questa misurazione presenta una significativa distorsione. Consideriamo una seconda applicazione container che ha un limite CPU di 800 m, come mostrato di seguito. Un'attività con un tempo di elaborazione di 400 ms verrà eseguita per 80 ms e poi sarà limitata per 20 ms in ciascuno dei primi quattro periodi di esecuzione di 100 ms. Sarà poi completato nel quinto periodo. Con il metodo attuale di misurazione del livello di throttling, si arriverà alla stessa percentuale: 80%. Ma è chiaro che questa seconda app soffre molto meno della prima app. Viene limitata a soli 20 ms * 4 = 80 ms in totale, ovvero solo una frazione dei 400 ms di tempo di esecuzione della CPU. Il livello di limitazione dell'80% attualmente misurato è troppo alto per riflettere la situazione reale di questa app.

Avevamo bisogno di un modo migliore per misurare il throttling e lo abbiamo creato:

Con il nuovo metodo, misuriamo il livello di throttling come la percentuale di tempo di throttling rispetto al tempo totale tra l'uso della CPU e il throttling. Ecco le nuove misurazioni delle due app sopra menzionate:

Questi due numeri, 55% e 17%, hanno più senso dell'80% originale. Non solo si tratta di due numeri diversi che differenziano i due scenari di applicazione, ma i rispettivi valori riflettono anche in modo più appropriato il vero impatto della limitazione, come si potrebbe forse visualizzare dai due grafici. Intuitivamente, la nuova misurazione può essere interpretata come la misura in cui il tempo complessivo di un'attività può essere migliorato/ridotto eliminando il throttling. Per la prima app, possiamo ridurre il tempo complessivo dell'attività di 240 ms (55% del totale). Per la seconda app, se eliminiamo il throttling, la percentuale sale solo al 17%, ma non è così significativa come per la prima app.

Di seguito sono riportati alcuni dati per confrontare le misurazioni di limitazione calcolate utilizzando i periodi di limitazione rispetto alla versione basata sul tempo.

Per un container con limiti di CPU bassi, la misurazione basata sul tempo mostra percentuali di throttling molto più elevate rispetto alla versione precedente che utilizza solo i periodi di throttling, come previsto.

Man mano che i limiti della CPU aumentano, le misurazioni basate sul tempo riflettono nuovamente con precisione percentuali di throttling più basse. Al contrario, la versione precedente mostra una percentuale di throttling molto più elevata, che può comportare un ridimensionamento aggressivo nonostante il limite della CPU sia sufficientemente alto.

Questa nuova misurazione del throttling è disponibile dalla versione 8.7.5 di IBM Turbonomic. Inoltre, nella versione 8.8.2, consentiamo anche agli utenti di personalizzare la tolleranza massima alla riduzione della velocità per ogni singola applicazione o gruppo di applicazioni, poiché riconosciamo pienamente che le diverse applicazioni hanno esigenze differenti in termini di tolleranza. Ad esempio, le applicazioni sensibili ai tempi di risposta, come le applicazioni di servizi Web, potrebbero avere una tolleranza inferiore, mentre le applicazioni batch, come i grandi lavori di apprendimento automatico, potrebbero avere una tolleranza molto più elevata. Ora gli utenti possono configurare il livello desiderato come preferiscono.